Method and apparatus for video encoding using intra block copy

Abstract

Methods, apparatus, and non-transitory computer-readable storage media for video decoding and encoding are provided. In one method for video encoding, a decoder may be based on a multi-model Intra Block Copy (IBC) encoded current block, where the multi-model IBC adaptively switches among different models. Further, the decoder may obtain one or more linear transform vectors (LTVs) for the current block.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is filed based on and claims priority to U.S. Provisional Application No. 63 / 401,569, filed on August 26, 2022, entitled “Method and Apparatus for Video Encoding Using Intra-Frame Block Copying,” the entire contents of which are incorporated by reference for all purposes. Technical Field

[0003] The present disclosure relates to video coding and compression, and in particular, but not limited to, methods and apparatus for improving intra-block copying methods in video encoding or decoding processes. Background Art

[0004] Various video coding techniques can be used to compress video data. Video coding is performed according to one or more video coding standards. For example, video coding standards include universal video coding (VVC), joint development test model (JEM), high efficiency video coding (HEVC / H.265), advanced video coding (AVC / H.264), moving picture experts group (MPEG) coding, etc. Video coding usually uses prediction methods (e.g., inter-frame prediction, intra-frame prediction, etc.), which use the redundancy inherent in video data. Video coding is intended to compress video data into a form using a lower bit rate while avoiding or minimizing the degradation of video quality.

[0005] The first version of the VVC standard was completed in July 2020, providing approximately 50% bitrate savings or equivalent perceptual quality compared to the previous generation video coding standard HEVC. Although the VVC standard provides significant codec improvements over its predecessor, there is evidence that superior coding efficiency can be achieved through additional coding tools. Recently, the Joint Video Development Team (JVET) under the cooperation of ITU-TVECG and ISO / IEC MPEG began to explore advanced technologies that can achieve substantial enhancements in codec efficiency relative to VVC. In April 2021, a software code base called the Enhanced Compression Model (ECM) was established for future video coding development work. The ECM reference software is based on the VVC Test Model (VTM) developed by JVET for VVC, in which several existing modules (e.g., intra / inter prediction, transform, loop filter, etc.) are further extended and / or improved. In the future, any new coding tools beyond the VVC standard need to be integrated into the ECM platform and tested using the JVET Common Test Conditions (CTC). Summary of the invention

[0006] This disclosure provides examples of techniques related to improving encoding and decoding efficiency of inter blocks.

[0007] According to a first aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may obtain a current block encoded by multi-model intra-block copy (IBC) based on IBC, wherein the multi-model IBC adaptively switches between different models. In addition, the decoder may obtain one or more linear transformation vectors (LTVs) for the current block.

[0008] According to a second aspect of the present disclosure, a method for video encoding is provided. In the method, an encoder may obtain one or more linear transformation vectors (LTVs) for a current block. In addition, the encoder may encode the current block based on a multi-model intra-frame block copy (IBC) adaptively switched among different models based on the one or more LTVs.

[0009] According to a third aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may parse the size of a block vector difference (BVD) component, parse a context-encoded BVD symbol prediction index, construct a plurality of BV candidates by creating a combination between a BVD symbol and a BVD absolute value and adding the combination to a BV prediction factor, derive a BVD symbol prediction cost for each BV candidate based on a template matching cost, sort the plurality of BV candidates based on the BVD symbol prediction cost, and derive a BVD symbol prediction index corresponding to a true BVD symbol.

[0010] According to a fourth aspect of the present disclosure, a method for video encoding is provided. In the method, the encoder may determine the size of a block vector difference (BVD) component, determine a BVD symbol prediction index that is context-coded, construct multiple BV candidates by creating a combination between a BVD symbol and a BVD absolute value and adding the combination to a BV prediction factor, determine a BVD symbol prediction cost for each BV candidate based on a template matching cost, sort the multiple BV candidates based on the BVD symbol prediction cost, and determine a BVD symbol prediction index corresponding to a true BVD symbol.

[0011] According to a fifth aspect of the present disclosure, a method for video decoding is provided. In the method, a decoder may obtain a bitstream including a current block, the current block being composed of a coding block based on at least one mode of an intra-frame mode or an inter-frame mode and an intra-frame block copy (IBC) mode. In addition, the decoder may decode the bitstream based on at least one mode of an intra-frame mode or an inter-frame mode and an IBC mode.

[0012] According to a sixth aspect of the present disclosure, a method for video encoding is provided. In the method, an encoder may encode a current block composed of coding blocks based on at least one of an intra mode or an inter mode and an intra block copy (IBC) mode, and send a bitstream including the current block to a decoder.

[0013] According to a seventh aspect of the present disclosure, a method for video decoding is provided, in which a decoder may obtain two or more block vectors (BVs) for a current block and obtain a final intra-block copy (IBC) prediction for the current block based on the two or more block vectors.

[0014] According to an eighth aspect of the present disclosure, a method for video encoding is provided, in which an encoder may obtain two or more block vectors (BVs) for a current block, and obtain a final intra-block copy (IBC) prediction for the current block based on the two or more block vectors.

[0015] According to a ninth aspect of the present disclosure, a device for video decoding is provided. The device may include one or more processors and a memory, the memory being coupled to the one or more processors and configured to store instructions executable by the one or more processors. In addition, when executing the instructions, the one or more processors are configured to perform the method according to the first aspect, the third aspect, the fifth aspect, or the seventh aspect.

[0016] According to a tenth aspect of the present disclosure, a device for video encoding is provided. The device may include one or more processors and a memory, the memory being coupled to the one or more processors and configured to store instructions executable by the one or more processors. In addition, when executing the instructions, the one or more processors are configured to perform the method according to the second aspect, the fourth aspect, the sixth aspect, or the eighth aspect.

[0017] According to the eleventh aspect of the present disclosure, a non-temporary computer-readable storage medium for storing computer-executable instructions is provided, wherein the computer-executable instructions, when executed by one or more computer processors, cause the one or more computer processors to receive a bit stream and, based on the bit stream, perform a method according to the first aspect, the third aspect, the fifth aspect or the seventh aspect.

[0018] According to the twelfth aspect of the present disclosure, a non-temporary computer-readable storage medium for storing computer-executable instructions is provided, wherein the computer-executable instructions, when executed by one or more computer processors, cause the one or more computer processors to perform the method according to the second aspect, the fourth aspect, the sixth aspect or the eighth aspect to encode a current block into a bit stream and send the bit stream.

[0019] According to a thirteenth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided for storing a bit stream to be decoded by the method according to the first aspect, the third aspect, the fifth aspect or the seventh aspect.

[0020] According to a fourteenth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided for storing a bit stream generated by skipping the method according to the second aspect, the fourth aspect, the sixth aspect or the eighth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] A more particular description of examples of the present disclosure will be presented by reference to specific examples shown in the accompanying drawings. Given that these drawings depict only some examples and are therefore not to be considered limiting in scope, the examples will be described and explained with additional specificity and detail through use of the accompanying drawings.

[0022] Figure 1A is a block diagram illustrating a system for encoding and decoding video blocks according to some examples of the present disclosure.

[0023] Figure 1B is a block diagram of an encoder according to some examples of the present disclosure.

[0024] Figure 1C to Figure 1F is a block diagram showing how a frame may be recursively partitioned into multiple video blocks of different sizes and shapes according to some examples of the present disclosure.

[0025] Figure 1G is a block diagram illustrating an exemplary video encoder according to some examples of the present disclosure.

[0026] Figure 2A is a block diagram of a decoder according to some examples of the present disclosure.

[0027] Figure 2B is a block diagram illustrating an exemplary video decoder according to some examples of the present disclosure.

[0028] Figure 3A is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0029] Figure 3B is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0030] Figure 3C is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0031] Figure 3D is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0032] Figure 3E is a diagram illustrating block partitioning in a multi-type tree structure according to some examples of the present disclosure.

[0033] FIG. 4A to FIG. 4B Examples of 4-parameter affine models according to some examples of the present disclosure are shown.

[0034] Figure 5 An example of a 6-parameter affine model according to some examples of the present disclosure is shown.

[0035] Figure 6 Neighboring neighboring blocks for inheriting affine merge candidates according to some examples of the present disclosure are shown.

[0036] Figure 7 Neighboring neighboring blocks used to construct affine merge candidates according to some examples of the present disclosure are shown.

[0037] Figure 8 The current CTU processing order and its available reference samples in the current CTU and the left CTU according to some examples of the present disclosure are shown.

[0038] Fig. 9 Padding candidates for replacing zero vectors in an IBC list according to some examples of the present disclosure are shown.

[0039] Fig.10 Reference regions for IBC when CTU(m,n) is encoded according to some examples of the present disclosure are shown.

[0040] Fig.11 IBC reference areas for camera-captured content are shown according to some examples of the present disclosure.

[0041] Figure 12A-12B Methods for dividing angle patterns according to some examples of the present disclosure are demonstrated.

[0042] Fig.13 Examples of different linear transformation models with different numbers of vectors are shown according to some examples of the present disclosure.

[0043] Fig.14 Reference sample point locations of a 6-parameter linear transformation model according to some examples of the present disclosure are shown.

[0044] Fig.15 Adjacent neighbors and non-adjacent neighbors for generating inheritance candidates according to some examples of the present disclosure are shown.

[0045] Fig.16 Adjacent neighbors and non-adjacent neighbors for generating construction candidates according to some examples of the present disclosure are shown.

[0046] Fig.17Shown is the inheritance of LTV from neighboring blocks through vector concatenation according to some examples of the present disclosure.

[0047] Fig.18 is a diagram illustrating a computing environment coupled to a user interface according to some examples of the present disclosure.

[0048] Fig.19 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0049] Fig. 20 is a diagram showing some examples according to the present disclosure. Fig.19 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding.

[0050] Fig.21 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0051] Fig. 22 is a diagram showing some examples according to the present disclosure. Fig.21 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding.

[0052] Fig.23 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0053] Fig.24 is a diagram showing some examples according to the present disclosure. Fig.23 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding.

[0054] Fig.25 is a flowchart illustrating a method for video decoding according to some examples of the present disclosure.

[0055] Fig.26 is a diagram showing some examples according to the present disclosure. Fig.25 The method for video decoding shown in FIG. 1 corresponds to a flowchart of a method for video encoding. DETAILED DESCRIPTION

[0056] Reference will now be made in detail to specific embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous non-limiting specific details are set forth to aid in understanding the subject matter presented herein. However, it will be apparent to one of ordinary skill in the art that various alternatives may be used. For example, it will be apparent to one of ordinary skill in the art that the subject matter presented herein may be implemented on many types of electronic devices having digital video capabilities.

[0057] The terms used in this disclosure are used only for the purpose of describing specific embodiments and are not intended to limit the disclosure. The singular forms of "a / an", "said" and "the" in this disclosure and the appended claims are also intended to include plural forms, unless otherwise clearly indicated throughout the disclosure. It should also be understood that the term "and / or" used in this disclosure refers to and includes one or any or all possible combinations of the listed multiple related items.

[0058] References throughout this specification to "one embodiment," "an embodiment," "an example," "some embodiments," "some examples," or similar language mean that the particular features, structures, or characteristics being described are included in at least one embodiment or example. Unless explicitly stated otherwise, features, structures, elements, or characteristics described in conjunction with one or some embodiments are also applicable to other embodiments.

[0059] Throughout the disclosure, unless otherwise explicitly stated, the terms "first", "second", "third", etc. are used only as nomenclature for reference to related elements (e.g., devices, components, compositions, steps, etc.), without implying any spatial or temporal order. For example, "first device" and "second device" may refer to two separately formed devices, or two parts, components, or operating states of the same device, and may be named arbitrarily.

[0060] The terms "module", "sub-module", "circuit", "sub-circuit", "circuitry", "sub-circuitry", "unit", or "sub-unit" may include a memory (shared, dedicated, or group) that stores code or instructions that can be executed by one or more processors. A module may include one or more circuits with or without stored code or instructions. A module or circuit may include one or more components that are directly or indirectly connected. These components may or may not be physically attached to each other or positioned adjacent to each other.

[0061] As used herein, the terms "if" or "when..." may be understood to mean "at..." or "in response to...", depending on the context. These terms, if they appear in a claim, may not indicate that the associated limitation or feature is conditional or optional. For example, a method may include the following steps: i) when condition X exists or if condition X exists, perform function or action X', and ii) when condition Y exists or if condition Y exists, perform function or action Y'. The method may be implemented with the ability to perform function or action X' and the ability to perform function or action Y'. Therefore, functions X' and Y' may be performed at different times during multiple executions of the method.

[0062] A unit or module may be implemented purely by software, purely by hardware, or by a combination of hardware and software. In a pure software implementation, for example, a unit or module may include functionally related code blocks or software components linked together directly or indirectly to perform a specific function.

[0063] Figure 1A is a block diagram illustrating an exemplary system 10 for encoding and decoding video blocks in parallel according to some embodiments of the present disclosure. Figure 1A As shown in , system 10 includes a source device 12 that generates and encodes video data to be later decoded by a destination device 14. Source device 12 and destination device 14 may include any of a wide variety of electronic devices, including desktop or laptop computers, tablet computers, smart phones, set-top boxes, digital televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc. In some implementations, source device 12 and destination device 14 are equipped with wireless communication capabilities.

[0064] In some embodiments, the target device 14 may receive the encoded video data to be decoded via the link 16. The link 16 may include any type of communication medium or device capable of moving the encoded video data from the source device 12 to the target device 14. In one example, the link 16 may include a communication medium that enables the source device 12 to directly send the encoded video data to the target device 14 in real time. The encoded video data may be modulated according to a communication standard (e.g., a wireless communication protocol) and sent to the target device 14. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form a portion of a packet-based network (e.g., a local area network, a wide area network, or a global network such as the Internet). The communication medium may include a router, a switch, a base station, or any other device that may be beneficial to facilitate communication from the source device 12 to the target device 14.

[0065] In some other embodiments, the encoded video data may be sent from the output interface 22 to a storage device 32. The encoded video data in the storage device 32 may then be accessed by the target device 14 via the input interface 28. The storage device 32 may include any of a variety of distributed or local information access data storage media, such as a hard drive, a Blu-ray disc, a digital versatile disc (DVD), a compact disc read-only memory (CD-ROM), a flash memory, a volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In another example, the storage device 32 may correspond to a file server or another intermediate storage device that may hold the encoded video data generated by the source device 12. The target device 14 may access the stored video data from the storage device 32 via streaming or downloading. The file server may be any type of computer capable of storing encoded video data and sending the encoded video data to the target device 14. Exemplary file servers include a network server (e.g., for a website), a file transfer protocol (FTP) server, a network attached storage (NAS) device, or a local information disk drive. Target device 14 may access the encoded video data through any standard data connection suitable for accessing encoded video data stored on a file server, including a wireless channel (e.g., a Wireless Fidelity (Wi-Fi) connection), a wired connection (e.g., a Digital Subscriber Line (DSL), a cable modem, etc.), or a combination of both wireless channels and wired connections. The transmission of the encoded video data from storage device 32 may be a streaming transmission, a download transmission, or a combination of both streaming and download transmissions.

[0066] like Figure 1A As shown in , source device 12 includes video source 18, video encoder 20 and output interface 22. Video source 18 may include sources such as or a combination of such sources: a video capture device (e.g., a camera), a video archive containing previously captured video, a video feed interface for receiving video from a video content provider, and / or a computer graphics system for generating computer graphics data as source video. As an example, if video source 18 is a camera of a security monitoring system, source device 12 and target device 14 may form a camera phone or a video phone. However, the embodiments described in this application may be generally applicable to video encoding and decoding, and may be applied to wireless and / or wired applications.

[0067] The captured, pre-captured, or computer-generated video may be encoded by the video encoder 20. The encoded video data may be sent directly to the target device 14 via the output interface 22 of the source device 12. The encoded video data may also (or alternatively) be stored on a storage device 32 for later access by the target device 14 or other device for decoding and / or playback. The output interface 22 may further include a modem and / or a transmitter.

[0068] Target device 14 includes input interface 28, video decoder 30, and display device 34. Input interface 28 may include a receiver and / or a modem and receives encoded video data via link 16. The encoded video data transmitted via link 16 or provided on storage device 32 may include various syntax elements generated by video encoder 20 for use by video decoder 30 in decoding the video data. Such syntax elements may be included within the encoded video data sent over a communication medium, stored on a storage medium, or stored on a file server.

[0069] In some implementations, the target device 14 may include a display device 34, which may be an integrated display device and an external display device configured to communicate with the target device 14. The display device 34 displays the decoded video data to a user and may include any of a variety of display devices, such as a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.

[0070] The video encoder 20 and the video decoder 30 can operate according to a proprietary standard or an industry standard (e.g., VVC, HEVC, Part 10 of MPEG-4, AVC) or an extension of such a standard. It should be understood that the present application is not limited to a specific video encoding / decoding standard and can be applied to other video encoding / decoding standards. It is generally believed that the video encoder 20 of the source device 12 can be configured to encode the video data according to any of these current standards or future standards. Similarly, it is also generally believed that the video decoder 30 of the target device 14 can be configured to decode the video data according to any of these current standards or future standards.

[0071] The video encoder 20 and the video decoder 30 may be implemented as any of a variety of suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic devices, software, hardware, firmware, or any combination thereof. When partially implemented in software, the electronic device may store instructions for the software in a suitable non-transitory computer-readable medium, and use one or more processors to execute the instructions in the hardware to perform the video encoding / decoding operations disclosed in the present disclosure. Each of the video encoder 20 and the video decoder 30 may be included in one or more encoders or decoders, and any of the encoders or decoders may be integrated as part of a combined encoder / decoder (CODEC) in the corresponding device.

[0072] Like HEVC, VVC is built on a block-based hybrid video coding framework. Figure 1B 1 is a block diagram illustrating a block-based video encoder according to some embodiments of the present disclosure. In the encoder 100, the input video signal is processed block by block, referred to as a coding unit (CU). The encoder 100 may be as follows: Figure 1A The video encoder 20 shown in . In VTM-1.0, a CU can be up to 128x128 pixels. However, unlike HEVC, which is based only on quadtree partitioning blocks, in VVC, a coding tree unit (CTU) is partitioned into CUs based on quadtree / binary tree / ternary tree to adapt to changing local characteristics. In addition, the concept of multiple partition unit types in HEVC is removed, that is, the separation of CU, prediction unit (PU) and transform unit (TU) no longer exists in VVC; instead, each CU is always used as a basic unit for both prediction and transformation without being further partitioned. In a multi-type tree structure, a CTU is first partitioned by a quadtree structure. Then, each quadtree leaf node can be further partitioned by a binary tree and a ternary tree structure.

[0073] FIG. 3A to FIG. 3E is a schematic diagram illustrating multiple types of tree splitting modes according to some embodiments of the present disclosure. FIG. 3A to FIG. 3E Five split types are shown, including four-way split ( Figure 3A ), vertical binary segmentation ( Figure 3B ), horizontal binary segmentation ( Figure 3C ), vertical ternary segmentation ( Figure 3D ) and horizontal ternary segmentation ( Figure 3E ).

[0074] For each given video block, spatial prediction and / or temporal prediction may be performed. Spatial prediction (or "intra-frame prediction") uses pixels from samples of encoded neighboring blocks in the same video picture / slice (which are called reference samples) to predict the current video block. Spatial prediction reduces the spatial redundancy inherent in video signals. Temporal prediction (also known as "inter-frame prediction" or "motion compensated prediction") uses reconstructed pixels from encoded video pictures to predict the current video block. Temporal prediction reduces the temporal redundancy inherent in video signals. The temporal prediction signal for a given CU is typically signaled by one or more motion vectors (MVs) indicating the amount and direction of motion between the current CU and its temporal reference. In addition, if multiple reference pictures are supported, a reference picture index is additionally sent, which is used to identify which reference picture in the reference picture storage the temporal prediction signal comes from.

[0075] After spatial and / or temporal prediction, an intra / inter mode decision circuit 121 in the encoder 100 selects the best prediction mode, for example based on a rate-distortion optimization method. The block prediction factor 120 is then subtracted from the current video block; and the resulting prediction residual is decorrelated using the transform circuit 102 and the quantization circuit 104. The resulting quantized residual coefficients are dequantized by the dequantization circuit 116 and inversely transformed by the inverse transform circuit 118 to form a reconstructed residual, which is then added back to the prediction block to form a reconstructed signal for the CU. In addition, before the reconstructed CU is placed in the reference picture storage of the picture buffer 117 and used to encode future video blocks, an in-loop filter 115, such as a deblocking filter, sample adaptive offset (SAO) and / or an adaptive loop filter (ALF), may be applied to the reconstructed CU. In order to form an output video bitstream 114, the coding mode (inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit 106 to be further compressed and packaged to form a bitstream.

[0076] For example, deblocking filters are available in the current versions of AVC, HEVC, and VVC. In HEVC, an additional loop filter called SAO is defined to further improve coding efficiency. In the current version of the VVC standard, another loop filter called ALF is being actively studied and is likely to be included in the final standard.

[0077] These loop filter operations are optional. Performing these operations helps improve coding efficiency and visual quality. They can also be turned off based on decisions made by encoder 100 to save computational complexity.

[0078] It should be noted that when these filter options are turned on by the encoder 100, intra prediction is typically based on unfiltered reconstructed pixels, while inter prediction is based on filtered reconstructed pixels.

[0079] Figure 2A is a block diagram illustrating a block-based video decoder 200 that can be used in conjunction with many video codec standards. The decoder 200 is similar to the one residing in Figure 1B The block-based video decoder 200 may be as follows: Figure 1A The video decoder 30 shown. In the decoder 200, the input video bitstream 201 is first decoded by entropy decoding 202 to derive quantized coefficient levels and prediction related information. The quantized coefficient levels are then processed by inverse quantization 204 and inverse transform 206 to obtain reconstructed prediction residuals. The block predictor mechanism implemented in the intra / inter mode selector 212 is configured to perform intra prediction 208 or motion compensation 210 based on the decoded prediction information. A set of unfiltered reconstructed pixels is obtained by summing the reconstructed prediction residual from the inverse transform 206 and the prediction output generated by the block predictor mechanism using an adder 214.

[0080] The reconstructed block may be further passed through a loop filter 209 before it is stored in a picture buffer 213 used as a reference picture storage. The reconstructed video in the picture buffer 213 may be sent to drive a display device, as well as used to predict future video blocks. In the case of enabling the loop filter 209, a filtering operation is performed on these reconstructed pixels to derive a final reconstructed video output 222.

[0081] Figure 1G is a block diagram illustrating another exemplary video encoder 20 according to some embodiments described in the present application. The video encoder 20 may perform intra-frame and inter-frame predictive coding and decoding of video blocks within a video frame. Intra-frame predictive coding and decoding relies on spatial prediction to reduce or remove spatial redundancy in video data within a given video frame or picture. Inter-frame predictive coding and decoding relies on temporal prediction to reduce or remove temporal redundancy in video data within adjacent video frames or pictures of a video sequence. It should be noted that the term "frame" may be used as a synonym for the term "image" or "picture" in the field of video coding and decoding.

[0082] like Figure 1GAs shown in FIG. 1 , the video encoder 20 includes a video data memory 40, a prediction processing unit 41, a decoded picture buffer (DPB) 64, an adder 50, a transform processing unit 52, a quantization unit 54, and an entropy coding unit 56. The prediction processing unit 41 further includes a motion estimation unit 42, a motion compensation unit 44, a segmentation unit 45, an intra-frame prediction processing unit 46, and an intra-frame block copy (BC) unit 48. In some embodiments, the video encoder 20 also includes an inverse quantization unit 58, an inverse transform processing unit 60, and an adder 62 for video block reconstruction. An in-loop filter 63 (e.g., a deblocking filter) may be located between the adder 62 and the DPB 64 to filter the block boundaries, thereby removing blockiness artifacts from the reconstructed video. In addition to the deblocking filter, another loop filter (e.g., a sample adaptive offset (SAO) filter and / or an adaptive loop filter (ALF)) may be used to filter the output of the adder 62. In some examples, the loop filter may be omitted, and the decoded video blocks may be provided by adder 62 directly to DPB 64. Video encoder 20 may take the form of fixed or programmable hardware units, or may be divided between one or more of the fixed or programmable hardware units shown.

[0083] Video data memory 40 may store video data to be encoded by components of video encoder 20. Figure 1A The video source 18 shown obtains video data in the video data memory 40. The DPB 64 is a buffer that stores reference video data (e.g., reference frames or pictures) for use by the video encoder 20 (e.g., in intra-frame or inter-frame prediction coding mode) when encoding the video data. The video data memory 40 and the DPB 64 can be formed by any of a variety of memory devices. In various examples, the video data memory 40 can be on-chip with other components of the video encoder 20, or off-chip relative to those components.

[0084] like Figure 1GAs shown in , after receiving the video data, the segmentation unit 45 within the prediction processing unit 41 segments the video data into video blocks. This segmentation may also include segmenting the video frame into strips, tiles (e.g., a set of video blocks) or other larger coding units (CUs) according to a predefined splitting structure associated with the video data (e.g., a quadtree (QT) structure). A video frame is or can be viewed as a two-dimensional array or matrix of samples having sample values. The samples in the array may also be referred to as pixels or picture elements (pel). The number of samples in the horizontal and vertical directions (or axes) of the array or picture defines the size and / or resolution of the video frame. For example, a video frame may be divided into multiple video blocks by using QT segmentation. A video block is again or may be viewed as a two-dimensional array or matrix of samples having sample values, but its dimension is smaller than the dimension of a video frame. The number of samples in the horizontal and vertical directions (or axes) of a video block defines the size of the video block. The video block may be further partitioned into one or more block partitions or sub-blocks (which may again form blocks) by, for example, iteratively using QT partitioning, binary tree (BT) partitioning or ternary tree (TT) partitioning or any combination thereof. It should be noted that the term "block" or "video block" used herein may be a portion of a frame or picture, in particular a rectangular (square or non-square) portion. With reference to, for example, HEVC and VVC, a block or video block may be or correspond to a coding tree unit (CTU), a CU, a prediction unit (PU) or a transform unit (TU) and / or may be or correspond to a corresponding block (e.g., a coding tree block (CTB), a coding block (CB), a prediction block (PB) or a transform block (TB)) and / or a sub-block.

[0085] The prediction processing unit 41 may select one of a plurality of feasible prediction coding modes for the current video block based on the error results (e.g., coding rate and distortion level), such as one of one or more inter-frame prediction coding modes in a plurality of intra-frame prediction coding modes. The prediction processing unit 41 may provide the resulting intra-frame prediction coding block or inter-frame prediction coding block to the adder 50 to generate a residual block, and to the adder 62 to reconstruct the coding block for subsequent use as part of a reference frame. The prediction processing unit 41 also provides syntax elements (e.g., motion vectors, intra-frame mode indicators, partition information, and other such syntax information) to the entropy coding unit 56.

[0086] To select an appropriate intra-prediction coding mode for the current video block, intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-prediction coding of the current video block in relation to one or more neighboring blocks in the same frame as the current block to be encoded to provide spatial prediction. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 may perform inter-prediction coding of the current video block in relation to one or more prediction blocks in one or more reference frames to provide temporal prediction. Video encoder 20 may perform multiple encoding passes, for example, to select an appropriate coding mode for each block of video data.

[0087] In some embodiments, the motion estimation unit 42 determines the inter-prediction mode for the current video frame by generating a motion vector according to a predetermined pattern within the sequence of video frames, the motion vector indicating the displacement of a video block within the current video frame relative to a prediction block within a reference video frame. Motion estimation performed by the motion estimation unit 42 is the process of generating a motion vector that estimates the motion for a video block. For example, a motion vector may indicate the displacement of a video block within a current video frame or picture relative to a prediction block within a reference frame associated with a current block being encoded within the current frame. The predetermined pattern may designate a video frame in a sequence as a P frame or a B frame. The intra BC unit 48 may determine a vector (e.g., a block vector) for intra BC coding in a manner similar to the motion vector determined by the motion estimation unit 42 for inter prediction, or may utilize the motion estimation unit 42 to determine the block vector.

[0088] The prediction block for the video block may be or may correspond to a block or reference block of a reference frame that is considered to closely match the video block to be encoded in terms of pixel difference, which may be determined by the sum of absolute differences (SAD), the sum of squared differences (SSD), or other difference metrics. In some embodiments, the video encoder 20 may calculate values ​​for sub-integer pixel positions of the reference frame stored in the DPB 64. For example, the video encoder 20 may interpolate values ​​for quarter-pixel positions, eighth-pixel positions, or other fractional pixel positions of the reference frame. Thus, the motion estimation unit 42 may perform a motion search relative to full pixel positions and fractional pixel positions and output a motion vector with fractional pixel accuracy.

[0089] Motion estimation unit 42 calculates a motion vector for a video block in an inter-prediction coded frame by comparing the position of the video block to the position of a prediction block of a reference frame selected from a first reference frame list (list 0) or a second reference frame list (list 1), each of which identifies one or more reference frames stored in DPB 64. Motion estimation unit 42 sends the calculated motion vector to motion compensation unit 44 and then to entropy encoding unit 56.

[0090] The motion compensation performed by the motion compensation unit 44 may involve obtaining or generating a prediction block based on the motion vector determined by the motion estimation unit 42. Upon receiving the motion vector for the current video block, the motion compensation unit 44 may locate the prediction block pointed to by the motion vector in one of the reference frame lists, retrieve the prediction block from the DPB 64, and forward the prediction block to the adder 50. The adder 50 then forms a residual video block of pixel difference values ​​by subtracting the pixel values ​​of the prediction block provided by the motion compensation unit 44 from the pixel values ​​of the current video block being encoded. The pixel difference values ​​forming the residual video block may include luminance component differences or chrominance component differences or both. The motion compensation unit 44 may also generate syntax elements associated with the video block of the video frame for use by the video decoder 30 when decoding the video block of the video frame. The syntax elements may include, for example, syntax elements defining a motion vector for identifying a prediction block, any flag indicating a prediction mode, or any other syntax information described herein. It should be noted that the motion estimation unit 42 and the motion compensation unit 44 may be highly integrated, but are described separately for conceptual purposes.

[0091] In some embodiments, the intra BC unit 48 may generate vectors and obtain prediction blocks in a manner similar to that described above in conjunction with the motion estimation unit 42 and the motion compensation unit 44, but these prediction blocks are in the same frame as the current block being encoded, and these vectors are referred to as block vectors rather than motion vectors. Specifically, the intra BC unit 48 may determine the intra prediction mode to be used to encode the current block. In some examples, the intra BC unit 48 may encode the current block using various intra prediction modes, for example, during separate encoding passes, and test their performance through rate-distortion analysis. Next, the intra BC unit 48 may select a suitable intra prediction mode to use among the various tested intra prediction modes and generate an intra mode indicator accordingly. For example, the intra BC unit 48 may calculate rate-distortion values ​​for the various tested intra prediction modes using rate-distortion analysis, and select an intra prediction mode with the best rate-distortion characteristic among the tested modes as a suitable intra prediction mode to use. The rate-distortion analysis generally determines the amount of distortion (or error) between a coded block and the original uncoded block that was encoded to produce the coded block, as well as the bit rate (i.e., the number of bits) used to produce the coded block. Intra BC unit 48 may calculate ratios based on the distortion and rate for the various coded blocks to determine which intra-prediction mode exhibits the best rate-distortion value for the block.

[0092] In other examples, intra BC unit 48 may use, in whole or in part, motion estimation unit 42 and motion compensation unit 44 to perform such functions for intra BC prediction in accordance with embodiments described herein. In either case, for intra block copying, the prediction block may be a block that is considered to closely match the block to be encoded in terms of pixel differences, which may be determined by SAD, SSD, or other difference metrics, and identifying the prediction block may include calculating values ​​for sub-integer pixel positions.

[0093] Regardless of whether the prediction block is from the same frame according to intra-frame prediction or from a different frame according to inter-frame prediction, the video encoder 20 can form a residual video block by subtracting the pixel values ​​of the prediction block from the pixel values ​​of the current video block being encoded. The pixel difference values ​​forming the residual video block may include both luma component differences and chroma component differences.

[0094] As an alternative to the inter-frame prediction performed by the motion estimation unit 42 and the motion compensation unit 44 or the intra-frame block copy prediction performed by the intra BC unit 48 as described above, the intra-frame prediction processing unit 46 can perform intra-frame prediction on the current video block. Specifically, the intra-frame prediction processing unit 46 can determine the intra-frame prediction mode for encoding the current block. To this end, the intra-frame prediction processing unit 46 can use various intra-frame prediction modes to encode the current block, for example, during separate encoding passes, and the intra-frame prediction processing unit 46 (or in some examples, the mode selection unit) can select a suitable intra-frame prediction mode from the tested intra-frame prediction modes to use. The intra-frame prediction processing unit 46 can provide information indicating the intra-frame prediction mode selected for the block to the entropy coding unit 56. The entropy coding unit 56 can encode the information indicating the selected intra-frame prediction mode into the bitstream.

[0095] After prediction processing unit 41 determines a prediction block for the current video block via inter-prediction or intra-prediction, adder 50 forms a residual video block by subtracting the prediction block from the current video block. The residual video data in the residual block may be included in one or more TUs and provided to transform processing unit 52. Transform processing unit 52 transforms the residual video data into residual transform coefficients using a transform (e.g., a discrete cosine transform (DCT) or a conceptually similar transform).

[0096] The transform processing unit 52 may send the resulting transform coefficients to a quantization unit 54. The quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may also reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting a quantization parameter. In some examples, the quantization unit 54 may then perform a scan on the matrix including the quantized transform coefficients. Alternatively, the entropy coding unit 56 may perform the scan.

[0097] After quantization, entropy coding unit 56 entropy encodes the quantized transform coefficients into a video bitstream using, for example, context adaptive variable length coding (CAVLC), context adaptive binary arithmetic coding (CABAC), syntax-based context adaptive binary arithmetic coding (SBAC), probability interval partitioning entropy (PIPE) coding, or another entropy coding method or technique. The encoded bitstream may then be sent to a video bitstream such as a Figure 1A The video decoder 30 shown, or archived as Figure 1A The video frame may be stored in storage device 32 as shown for later transmission to or retrieval by video decoder 30. Entropy encoding unit 56 may also entropy encode motion vectors and other syntax elements for the current video frame being encoded.

[0098] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual video block in the pixel domain for use in generating reference blocks for predicting other video blocks. As noted above, motion compensation unit 44 may generate a motion compensated prediction block from one or more reference blocks of a frame stored in DPB 64. Motion compensation unit 44 may also apply one or more interpolation filters to the prediction block to calculate sub-integer pixel values ​​for use in motion estimation.

[0099] Adder 62 adds the reconstructed residual block to the motion compensated prediction block generated by motion compensation unit 44 to generate a reference block for storage in DPB 64. The reference block may then be used as a prediction block by intra BC unit 48, motion estimation unit 42, and motion compensation unit 44 to inter-predict another video block in a subsequent video frame.

[0100] Figure 2B 1 is a block diagram showing another exemplary video decoder 30 according to some embodiments of the present application. The video decoder 30 includes a video data memory 79, an entropy decoding unit 80, a prediction processing unit 81, an inverse quantization unit 86, an inverse transform processing unit 88, an adder 90, and a DPB 92. The prediction processing unit 81 further includes a motion compensation unit 82, an intra-frame prediction unit 84, and an intra-frame BC unit 85. The video decoder 30 may perform the above-mentioned operations in combination with the above-mentioned operations. Figure 1G The encoding process is substantially the inverse of the decoding process described with respect to video encoder 20. For example, motion compensation unit 82 may generate prediction data based on motion vectors received from entropy decoding unit 80, and intra-prediction unit 84 may generate prediction data based on intra-prediction mode indicators received from entropy decoding unit 80.

[0101] In some examples, units of the video decoder 30 may be tasked to perform embodiments of the present application. In addition, in some examples, embodiments of the present disclosure may be dispersed in one or more of the units of the video decoder 30. For example, the intra BC unit 85 may perform embodiments of the present application alone or in combination with other units of the video decoder 30 (e.g., the motion compensation unit 82, the intra prediction unit 84, and the entropy decoding unit 80). In some examples, the video decoder 30 may not include the intra BC unit 85, and the functions of the intra BC unit 85 may be performed by other components of the prediction processing unit 81 (e.g., the motion compensation unit 82).

[0102] The video data memory 79 may store video data, such as an encoded video bitstream, to be decoded by other components of the video decoder 30. The video data stored in the video data memory 79 may be obtained, for example, from the storage device 32, from a local information video source (e.g., a camera), via a wired or wireless network communication of video data, or by accessing a physical data storage medium (e.g., a flash drive or hard drive). The video data memory 79 may include a coded picture buffer (CPB) that stores encoded video data from an encoded video bitstream. The DPB 92 of the video decoder 30 stores reference video data for use by the video decoder 30 (e.g., in intra-frame or inter-frame prediction coding mode) when decoding the video data. The video data memory 79 and the DPB 92 may be formed by any of a variety of memory devices, such as dynamic random access memory (DRAM) (including synchronous DRAM (SDRAM)), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. For illustrative purposes, the video data memory 79 and the DPB 92 are shown in FIG. Figure 2B 92 are depicted as two different components of the video decoder 30. However, it will be apparent to those skilled in the art that the video data memory 79 and the DPB 92 can be provided by the same memory device or separate memory devices. In some examples, the video data memory 79 can be on-chip with other components of the video decoder 30, or off-chip relative to those components.

[0103] During the decoding process, the video decoder 30 receives an encoded video bitstream representing video blocks of an encoded video frame and associated syntax elements. The video decoder 30 may receive syntax elements at the video frame level and / or the video block level. The entropy decoding unit 80 of the video decoder 30 entropy decodes the bitstream to generate quantization coefficients, motion vectors or intra-frame prediction mode indicators, and other syntax elements. The entropy decoding unit 80 then forwards the motion vectors or intra-frame prediction mode indicators, and other syntax elements to the prediction processing unit 81.

[0104] When a video frame is encoded as an intra-prediction coded (I) frame or for intra-coded prediction blocks in other types of frames, the intra-prediction unit 84 of the prediction processing unit 81 can generate prediction data for a video block of the current video frame based on the intra-prediction mode transmitted by the signal and reference data from a previously decoded block of the current frame.

[0105] When the video frame is encoded as an inter-frame prediction coded (i.e., B or P) frame, the motion compensation unit 82 of the prediction processing unit 81 generates one or more prediction blocks for the video block of the current video frame based on the motion vector and other syntax elements received from the entropy decoding unit 80. Each of the prediction blocks can be generated from a reference frame within one of the reference frame lists. The video decoder 30 can construct the reference frame lists, i.e., List 0 and List 1, using a default construction technique based on the reference frames stored in the DPB 92.

[0106] In some examples, when the video block is encoded according to the intra BC mode described herein, intra BC unit 85 of prediction processing unit 81 generates a prediction block for the current video block based on the block vector and other syntax elements received from entropy decoding unit 80. The prediction block may be within a reconstruction region of the same picture as the current video block as defined by video encoder 20.

[0107] The motion compensation unit 82 and / or the intra BC unit 85 determine prediction information for a video block of the current video frame by parsing the motion vector and other syntax elements, and then use the prediction information to generate a prediction block for the current video block being decoded. For example, the motion compensation unit 82 uses some of the received syntax elements to determine a prediction mode (e.g., intra prediction or inter prediction) for encoding a video block of a video frame, an inter prediction frame type (e.g., B or P), construction information for one or more of the reference frame lists for the frame, motion vectors for each inter prediction encoded video block of the frame, inter prediction states for each inter prediction encoded video block of the frame, and other information for decoding a video block in the current video frame.

[0108] Similarly, the intra BC unit 85 may use some of the received syntax elements, such as flags, to determine whether the current video block is predicted using intra BC mode, construction information of which video blocks of the frame are within the reconstruction region and should be stored in the DPB 92, block vectors for each intra BC predicted video block of the frame, intra BC prediction status for each intra BC predicted video block of the frame, and other information for decoding the video blocks in the current video frame.

[0109] Motion compensation unit 82 may also perform interpolation using interpolation filters as used by video encoder 20 during encoding of the video blocks to calculate interpolated values ​​for sub-integer pixels of reference blocks. In this case, motion compensation unit 82 may determine the interpolation filters used by video encoder 20 based on the received syntax elements and use these interpolation filters to produce the prediction block.

[0110] Inverse quantization unit 86 inverse quantizes the quantized transform coefficients provided in the bitstream and entropy decoded by entropy decoding unit 80, using the same quantization parameters calculated by video encoder 20 for each video block in the video frame to determine the degree of quantization. Inverse transform processing unit 88 applies an inverse transform (e.g., an inverse DCT, an inverse integer transform, or a conceptually similar inverse transform process) to the transform coefficients to reconstruct the residual block in the pixel domain.

[0111] After the motion compensation unit 82 or the intra BC unit 85 generates a prediction block for the current video block based on the vector and other syntax elements, the adder 90 reconstructs the decoded video block for the current video block by adding the residual block from the inverse transform processing unit 88 to the corresponding prediction block generated by the motion compensation unit 82 and the intra BC unit 85. A loop filter 91 (e.g., a deblocking filter, an SAO filter, and / or an ALF) may be located between the adder 90 and the DPB 92 to further process the decoded video block. In some examples, the loop filter 91 may be omitted, and the decoded video block may be provided directly to the DPB 92 by the adder 90. The decoded video blocks in a given frame are then stored in the DPB 92, which stores reference frames for subsequent motion compensation of the next video block. The DPB 92 or a memory device separate from the DPB 92 may also store the decoded video for later presentation on a display device (e.g., Figure 1A on a display device 34).

[0112] In the current VVC and AVS3 standards, the motion information of the current coding block is either copied from the spatial neighboring blocks or the temporal neighboring blocks specified by the merge candidate index, or obtained through explicit signaling of motion estimation. The focus of the present disclosure is to improve the accuracy of the motion vector used for the affine merge mode by improving the derivation method of the affine merge candidate. For the convenience of describing the present disclosure, the existing affine merge mode design in the VVC standard is taken as an example to illustrate the proposed ideas. Please note that although the existing affine mode design in the VVC standard is used as an example throughout the present disclosure, for technicians in the field of modern video coding and decoding technology, the proposed technology can also be applied to different designs of affine motion prediction modes or other coding tools with the same or similar design spirit.

[0113] In a typical video encoding process, a video sequence typically includes an ordered set of frames or pictures. Each frame may include three sample arrays, denoted SL, SCb, and SCr. SL is a two-dimensional array of luma samples. SCb is a two-dimensional array of Cb chroma samples. SCr is a two-dimensional array of Cr chroma samples. In other examples, a frame may be monochrome and therefore include only a two-dimensional array of luma samples.

[0114] like Figure 1C As shown in , the video encoder 20 (or more specifically, the segmentation unit of the pre-processing unit of the video encoder 20) generates an encoded representation of a frame by first segmenting the frame into a set of CTUs. A video frame may include an integer number of CTUs sequentially ordered from left to right and from top to bottom in a raster scan order. Each CTU is the largest logical coding unit, and the width and height of the CTU are signaled by the video encoder 20 in a sequence parameter set so that all CTUs in a video sequence have the same size, one of 128×128, 64×64, 32×32, and 16×16. It should be noted, however, that the present application is not necessarily limited to a particular size. As Figure 1D As shown in , each CTU may include one CTB for luma samples, two corresponding coding tree blocks for chroma samples, and syntax elements for encoding the samples of the coding tree blocks. The syntax elements describe the properties of different types of units of coding pixel blocks and how the video sequence can be reconstructed at the video decoder 30, including inter-frame prediction or intra-frame prediction, intra-frame prediction mode, motion vectors, and other parameters. In a monochrome picture or a picture with three separate color planes, a CTU may include a single coding tree block and syntax elements for encoding the samples of the coding tree block. The coding tree block may be an N×N block of samples.

[0115] To achieve better performance, the video encoder 20 may recursively perform tree partitioning, such as binary tree partitioning, ternary tree partitioning, quadtree partitioning, or a combination thereof, on the coding tree block of the CTU and divide the CTU into smaller CUs. Figure 1E As depicted in , a 64×64 CTU 400 is first divided into four smaller CUs, each CU having a block size of 32×32. Among the four smaller CUs, CU 410 and CU 420 are respectively divided into four CUs with a block size of 16×16. Two 16×16 CUs 430 and CU 440 are further divided into four CUs with a block size of 8×8. Figure 1F Depicted is a diagram showing Figure 1E The quadtree data structure of the final result of the partitioning process of the CTU 400 depicted in FIG. 4 corresponds to a CU of a corresponding size ranging from 32×32 to 8×8. Figure 1DEach CU may include a CB of luma samples and two corresponding coding blocks of chroma samples of the same size frame, and syntax elements for encoding the samples of the coding blocks. In a monochrome picture or a picture with three separate color planes, a CU may include a single coding block and syntax structures for encoding the samples of the coding block. It should be noted that Figure 1E and Figure 1F The quadtree partitioning depicted in FIG is for illustrative purposes only, and one CTU can be split into multiple CUs based on quadtree partitioning / ternary tree partitioning / binary tree partitioning to adapt to varying local characteristics. In a multi-type tree structure, one CTU is partitioned according to a quadtree structure, and each quadtree leaf CU can be further partitioned according to a binary and ternary tree structure. FIG. 3A to FIG. 3E As shown, there are five possible partitioning types for a coding block with width W and height H, namely, quadruple partitioning, horizontal binary partitioning, vertical binary partitioning, horizontal ternary partitioning, and vertical ternary partitioning.

[0116] In some embodiments, the video encoder 20 may further partition the coding block of the CU into one or more (M×N) PBs. A PB is a rectangular (square or non-square) sample block to which the same prediction (inter or intra) is applied. The PU of a CU may include a PB of luma samples, two corresponding PBs of chroma samples, and syntax elements for predicting the PBs. In a monochrome picture or a picture with three separate color planes, a PU may include a single PB and a syntax structure for predicting the PB. The video encoder 20 may generate a predicted luma block, a predicted Cb block, and a predicted Cr block for the luma PB, Cb PB, and Cr PB of each PU of the CU.

[0117] Video encoder 20 may use intra prediction or inter prediction to generate a prediction block for a PU. If video encoder 20 uses intra prediction to generate a prediction block for a PU, video encoder 20 may generate the prediction block for the PU based on decoded samples of a frame associated with the PU. If video encoder 20 uses inter prediction to generate a prediction block for a PU, video encoder 20 may generate the prediction block for the PU based on decoded samples of one or more frames other than the frame associated with the PU.

[0118] After the video encoder 20 generates the predicted luma block, the predicted Cb block, and the predicted Cr block for one or more PUs of a CU, the video encoder 20 may generate a luma residual block for the CU by subtracting the predicted luma block of the CU from the original luma coding block of the CU, so that each sample in the luma residual block of the CU indicates the difference between a luma sample in one of the predicted luma blocks of the CU and a corresponding sample in the original luma coding block of the CU. Similarly, the video encoder 20 may generate a Cb residual block and a Cr residual block for the CU, respectively, so that each sample in the Cb residual block of the CU indicates the difference between a Cb sample in one of the predicted Cb blocks of the CU and a corresponding sample in the original Cb coding block of the CU, and each sample in the Cr residual block of the CU may indicate the difference between a Cr sample in one of the predicted Cr blocks of the CU and a corresponding sample in the original Cr coding block of the CU.

[0119] In addition, if Figure 1E As shown in , the video encoder 20 can use quadtree partitioning to decompose the luma residual block, Cb residual block and Cr residual block of the CU into one or more luma transform blocks, Cb transform blocks and Cr transform blocks, respectively. A transform block is a rectangular (square or non-square) sample block to which the same transform is applied. The TU of a CU may include a transform block of luma samples, two corresponding transform blocks of chroma samples, and syntax elements for transforming the transform block samples. Therefore, each TU of a CU may be associated with a luma transform block, a Cb transform block and a Cr transform block. In some examples, the luma transform block associated with the TU may be a sub-block of the luma residual block of the CU. The Cb transform block may be a sub-block of the Cb residual block of the CU. The Cr transform block may be a sub-block of the Cr residual block of the CU. In a monochrome picture or a picture with three separate color planes, a TU may include a single transform block and a syntax structure for transforming the samples of the transform block.

[0120] Video encoder 20 may apply one or more transforms to a luma transform block of a TU to generate a luma coefficient block of the TU. A coefficient block may be a two-dimensional array of transform coefficients. A transform coefficient may be a scalar. Video encoder 20 may apply one or more transforms to a Cb transform block of a TU to generate a Cb coefficient block of the TU. Video encoder 20 may apply one or more transforms to a Cr transform block of a TU to generate a Cr coefficient block of the TU.

[0121] The video encoder 20 may apply one or more transforms to the luma transform block of the TU to generate a luma coefficient block for the TU. The coefficient block may be a two-dimensional array of transform coefficients. The transform coefficient may be a scalar. The video encoder 20 may apply one or more transforms to the Cb transform block of the TU to generate a Cb coefficient block for the TU. The video encoder 20 may apply one or more transforms to the Cr transform block of the TU to generate a Cr coefficient block for the TU.

[0122] After generating a coefficient block (e.g., a luma coefficient block, a Cb coefficient block, or a Cr coefficient block), the video encoder 20 may quantize the coefficient block. Quantization generally refers to a process in which transform coefficients are quantized to potentially reduce the amount of data used to represent the transform coefficients, thereby providing further compression. After the video encoder 20 quantizes the coefficient block, the video encoder 20 may entropy encode syntax elements indicating the quantized transform coefficients. For example, the video encoder 20 may perform CABAC on the syntax elements indicating the quantized transform coefficients. Finally, the video encoder 20 may output a bitstream including a sequence of bits that form a representation of an encoded frame and associated data, and the bitstream is stored in the storage device 32 or sent to the target device 14.

[0123] After receiving the bitstream generated by the video encoder 20, the video decoder 30 can parse the bitstream to obtain syntax elements from the bitstream. The video decoder 30 can reconstruct the frame of the video data based at least in part on the syntax elements obtained from the bitstream. The process of reconstructing the video data is generally inverse to the encoding process performed by the video encoder 20. For example, the video decoder 30 can perform an inverse transform on the coefficient block associated with the TU of the current CU to reconstruct the residual block associated with the TU of the current CU. The video decoder 30 also reconstructs the coding block of the current CU by adding the samples of the prediction block for the PU of the current CU to the corresponding samples of the transform block of the TU of the current CU. After reconstructing the coding block for each CU of the frame, the video decoder 30 can reconstruct the frame.

[0124] As mentioned above, video coding mainly uses two modes, namely, intra-frame prediction (or intra-frame prediction) and inter-frame prediction (or inter-frame prediction) to achieve video compression. It should be noted that IBC can be regarded as intra-frame prediction or a third mode. Between the two modes, inter-frame prediction contributes more to coding efficiency than intra-frame prediction because motion vectors are used to predict the current video block based on the reference video block.

[0125] But with the ever-improving video data capture technology and finer video block sizes for retaining details in the video data, the amount of data required to represent the motion vector for the current frame has also increased significantly. One way to overcome this challenge benefits from the fact that not only a set of neighboring CUs in both the spatial and temporal domains have similar video data for prediction purposes, but also the motion vectors between these neighboring CUs are similar. Therefore, the motion information of spatially neighboring CUs and / or temporally co-located CUs can be used as an approximation of the motion information (e.g., motion vector) of the current CU (which is also called the "motion vector predictor" (MVP) of the current CU) by exploring their spatial and temporal correlations.

[0126] Instead of combining as above Figure 2A The actual motion vector of the current CU determined by the motion estimation unit is encoded into the video bitstream, and the motion vector predictor of the current CU is subtracted from the actual motion vector of the current CU to generate a motion vector difference (MVD) for the current CU. By doing so, the motion vector determined by the motion estimation unit for each CU of the frame does not need to be encoded into the video bitstream, and the amount of data used to represent the motion information in the video bitstream can be significantly reduced.

[0127] Similar to the process of selecting a prediction block in a reference frame during inter-frame prediction of a coding block, both the video encoder 20 and the video decoder 30 need to adopt a set of rules for constructing a motion vector candidate list (also called a "merge list") for the current CU using those potential candidate motion vectors associated with the spatial neighboring CUs and / or temporal co-located CUs of the current CU, and then selecting a member from the motion vector candidate list as the motion vector predictor for the current CU. By doing so, the motion vector candidate list itself does not need to be sent from the video encoder 20 to the video decoder 30, and the index of the selected motion vector predictor within the motion vector candidate list is sufficient for the video encoder 20 and the video decoder 30 to use the same motion vector predictor within the motion vector candidate list to encode and decode the current CU.

[0128] Affine Model

[0129] In HEVC, only the translational motion model is applied to motion compensation prediction. In the real world, there are many kinds of motion, such as zooming in / out, rotation, perspective motion, and other irregular motions. In VVC, affine motion compensation prediction is applied by signaling a flag for each inter-frame coding block to indicate whether the translational motion model or the affine motion model is applied to the inter-frame prediction. In the current VVC, two affine modes including a 4-parameter affine mode and a 6-parameter affine mode are supported for one affine coding block.

[0130] The 4-parameter affine model has the following parameters: two parameters for translational movement in the horizontal and vertical directions respectively, one parameter for scaling movement, and one parameter for rotational movement in both directions. In this model, the horizontal scaling parameter is equal to the vertical scaling parameter, and the horizontal rotation parameter is equal to the vertical rotation parameter. In order to achieve a better adaptation of the motion vectors and affine parameters, those affine parameters are derived from two MVs located at the top left and top right corners of the current block, which are also called control point motion vectors (CPMVs). As FIG. 4A to FIG. 4B As shown in , the affine motion field of a block is described by two CPMVs (V0, V1). Based on the motion of the control points, an affine coded block motion field (v x ,vy ) is described as:

[0131]

[0132] The 6-parameter affine model has the following parameters: two parameters for horizontal and vertical translation, two parameters for horizontal scaling and rotation, and two parameters for vertical scaling and rotation. The 6-parameter affine motion model is encoded and decoded using three CPMVs. Figure 5 As shown in , the three control points of a 6-parameter affine block are located at the top left, top right, and bottom left corners of the block. The motion at the top left control point is associated with translational motion, and the motion at the top right control point is associated with rotation and scaling motion in the horizontal direction, and the motion at the bottom left control point is associated with rotation and scaling motion in the vertical direction. Compared with the 4-parameter affine motion model, the 6-parameter horizontal rotation and scaling motion can be different from the vertical rotation and scaling motion. Assume (V0, V1, V2) is Figure 5 The MVs of the upper left, upper right, and lower left corners of the current block in , using the three MVs at the control point, and the motion vector (v x ,v y ) is exported as:

[0133]

[0134] Affine merge mode

[0135] In affine merge mode, the CPMV for the current block is not explicitly signaled, but derived from neighboring blocks. Specifically, in this mode, the motion information of spatially neighboring blocks is used to generate the CPMV for the current block. The affine merge mode candidate list has a finite size. For example, in the current VVC design, there may be up to five candidates. The encoder may evaluate and select the best candidate index based on a rate-distortion optimization algorithm. The selected candidate index is then signaled to the decoder side. Affine merge candidates may be decided in three ways:

[0136] ●Inherited from neighboring affine encoding blocks

[0137] ● Constructed from translated MVs from neighboring blocks

[0138] ●Zero MV

[0139] For the inheritance method, there may be up to two candidates. From the neighboring block located at the lower left of the current block (e.g., Figure 6 As shown, the scanning order is to obtain candidates from A0 to A1), and if available, from the neighboring block located at the upper right of the current block (for example, Figure 6 As shown, the scanning order is from B0 to B2) to obtain candidates.

[0140] For the construction method, the candidate is a combination of the translated MVs of the neighbors, and the candidate can be generated in two steps.

[0141] • Step 1: Get four translation MVs from available neighbors.

[0142] ○MV1: The MV from one of the three neighboring blocks close to the upper left corner of the current block. Figure 7 As shown, the scanning order is B2, B3 and A2.

[0143] ○MV2: The MV from one of the two neighboring blocks close to the upper right corner of the current block. Figure 7 As shown, the scanning order is B1 and B0.

[0144] ○MV3: The MV from one of the two neighboring blocks close to the lower left corner of the current block. Figure 7 As shown, the scanning order is A1 and A0.

[0145] ○MV4: The MV of the temporally co-located block from the neighboring block close to the lower right corner of the current block. As shown in the figure, the neighboring block is T.

[0146] • Step 2: Derive a combination based on the four translated MVs from step 1.

[0147] ○ Combination 1: MV1, MV2, MV3

[0148] ○ Combination 2: MV1, MV2, MV4

[0149] ○ Combination 3: MV1, MV3, MV4

[0150] ○ Combination 4: MV2, MV3, MV4

[0151] ○ Combination 5: MV1, MV2

[0152] ○ Combination 6: MV1, MV3

[0153] When the merge candidate list is not full after populating with inherited candidates and constructed candidates, a zero MV is inserted at the end of the list.

[0154] Affine AMVP mode

[0155] Affine AMVP (Advanced Motion Vector Prediction) mode can be applied to CUs with width and height both greater than or equal to 16. An affine flag in the CU level is signaled in the bitstream to indicate whether the affine AMVP mode is used, and then another flag is signaled to indicate whether it is 4-parameter affine or 6-parameter affine. In this mode, the difference between the CPMV of the current CU and its predictor CPMVP is signaled in the bitstream. The affine AMVP candidate list size is 2 and the affine AMVP candidate list is generated by using the following four types of CPMV candidates in order:

[0156] – Inherited affine AMVP candidates extrapolated from the CPMV of neighboring CUs

[0157] – Constructed affine AMVP candidate CPMVP derived using the translation MV of the neighboring CU

[0158] –Translated MV from neighboring CU

[0159] – Time MV from the same CU

[0160] –Zero MV

[0161] The order of checking inherited affine AMVP candidates is the same as that of checking inherited affine merge candidates. The only difference is that for AMVP candidates, only affine CUs with the same reference picture as the current block are considered. No pruning is applied when inserting inherited affine motion predictors into the candidate list.

[0162] The constructed AMVP candidates are derived from the same spatial neighbors as the affine merge mode. The same check order as performed in the affine merge candidate construction is used. In addition, the reference picture index of the neighboring blocks is also checked. The first block in the check order is used, which is inter-coded and has the same reference picture as the current CU. When the current CU is encoded in 4-parameter affine mode and both mv0 and mv1 are available, mv0 and mv1 are added as a candidate in the affine AMVP candidate list. When the current CU is encoded in 6-parameter affine mode and all three CPMVs are available, it is added as a candidate in the affine AMVP candidate list. Otherwise, the constructed AMVP candidate is set to unavailable.

[0163] If the affine AMVP list candidates are still less than 2 after inserting the valid inherited affine AMVP candidates and constructed AMVP candidates, mv0, mv1, and mv2 will be added in order as translation MVs to predict all control point MVs of the current CU (when available). Finally, if the affine AMVP list is still not full, the affine AMVP list is filled with zero MVs.

[0164] Intra-block copying in Versatile Video Coding (VVC)

[0165] Intra-block copying (IBC) is a tool adopted in the HEVC extension regarding SCC. As we all know, it significantly improves the encoding and decoding efficiency of screen content materials. Since the IBC mode is implemented as a block-level coding mode, block matching (BM) is performed at the encoder to find the optimal block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to the reference block that has been reconstructed in the current picture. The luminance block vector of the IBC-encoded CU is integer precision. The chrominance block vector is also rounded to integer precision. When combined with AMVR, the IBC mode can switch between 1-pixel and 4-pixel motion vector precision. The IBC-encoded CU is regarded as a third prediction mode in addition to the intra-frame prediction mode or the inter-frame prediction mode. The IBC mode is applicable to CUs with both width and height less than or equal to 64 luminance samples.

[0166] On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs RD checks on blocks with a width or height no greater than 16 luma samples. For non-merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a local search based on block matching is performed.

[0167] In hash-based search, the hash key matching (32-bit CRC) between the current block and the reference blocks is extended to all allowed block sizes. The hash key calculation for each position in the current image is based on 4×4 sub-blocks. For larger-sized current blocks, the hash key is determined to match the hash key of the reference block when all hash keys of all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If the hash keys of multiple reference blocks are found to match the hash key of the current block, the block vector cost of each matching reference is calculated and the block vector cost with the minimum cost is selected.

[0168] In the block matching search, the search range is set to cover both the previous CTU and the current CTU.

[0169] At CU level, IBC mode is signaled and it can be signaled as IBC AMVP mode or IBC Skip / Merge mode as follows:

[0170] IBC skip / merge mode: The merge candidate index is used to indicate which block vectors from the list of neighboring candidate IBC coded blocks are used to predict the current block. The merge list consists of spatial candidates, HMVP candidates, and pairwise candidates.

[0171] IBC AMVP mode: Block vector differences are encoded in the same way as motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the upper neighbor (if IBC encoded). When either neighbor is not available, the default block vector will be used as the predictor. A flag is signaled to indicate the block vector predictor index.

[0172] IBC Reference Area

[0173] In order to reduce memory consumption and decoder complexity, IBC in VVC only allows the reconstruction of predefined areas including the area of ​​the current CTU and some areas of the left CTU. Figure 8 Except for the reference area of ​​IBC mode, each block represents a 64×64 luma sample unit.

[0174] Depending on the location of the current coded CU position within the current CTU, the following applies:

[0175] If the current block falls into the upper left 64×64 block of the current CTU, in addition to the reconstructed samples in the current CTU, it can also use the CPR mode to refer to the reference samples in the lower right 64×64 block of the left CTU. The current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block of the left CTU and the reference samples in the upper right 64×64 block of the left CTU.

[0176] If the current block falls into the upper right 64×64 block of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the brightness position (0,64) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block and the lower right 64×64 block of the left CTU; otherwise, the current block can also refer to the reference samples in the lower right 64×64 block of the left CTU.

[0177] If the current block falls into the lower left 64×64 block of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the luma position (64,0) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the upper right 64×64 block and the lower right 64×64 block of the left CTU. Otherwise, the current block can also use the CPR mode to refer to the reference samples in the lower right 64x64 block of the left CTU.

[0178] If the current block falls into the lower right 64×64 block of the current CTU, it can use the CPR mode to refer only to the already reconstructed samples in the current CTU.

[0179] This restriction allows the IBC mode to be implemented using local information on-chip memory for hardware implementation.

[0180] Interaction of IBC with other coding tools

[0181] The interaction between IBC mode and other inter-coding tools in VVC, such as pairwise merge candidates, history-based motion vector predictor (HMVP), combined intra / inter prediction mode (CIIP), merge mode with motion vector difference (MMVD), and geometric partitioning mode (GPM), is as follows:

[0182] – IBC can be used with pairwise merge candidates and HMVP. A new pairwise IBC merge candidate can be generated by averaging two IBC merge candidates. For HMVP, IBC motion is inserted into the history buffer for future reference.

[0183] – IBC cannot be used in combination with the following interframe tools: Affine Motion, CIIP, MMVD, and GPM.

[0184] – When DUAL_TREE partitioning is used, IBC is not allowed for chroma coded blocks.

[0185] Unlike the HEVC screen content coding extension, the current picture is no longer included as one of the reference pictures in the reference picture list 0 for IBC prediction. The derivation process of motion vectors for IBC mode excludes all neighboring blocks in inter mode, and vice versa. The following IBC design aspects apply:

[0186] – IBC shares the same process as in regular MV merging including pairwise merging candidates and history-based motion predictors, but TMVP and zero vectors are not allowed since they are invalid for IBC mode.

[0187] – Separate HMVP buffers (5 candidates each) for regular MV and IBC.

[0188] – Block vector constraints are implemented in the form of bitstream consistency constraints, the encoder needs to ensure that there are no invalid vectors in the bitstream, and if the merge candidate is invalid (out of range or zero), then the merge should not be used. This bitstream consistency constraint is expressed in terms of a virtual buffer as described below.

[0189] – For deblocking, IBC is treated as inter mode.

[0190] – If the current block is encoded using IBC prediction mode, AMVR does not use quarter pixels; instead,

[0191] AMVR is signaled to indicate only whether the MV is inter-pixel or 4-integer-pixel.

[0192] - The number of IBC merge candidates may be signaled in the slice header separately from the number of regular merge candidates, sub-block merge candidates, and geometric merge candidates.

[0193] The virtual buffer concept is used to describe the allowable reference area and valid block vectors for the IBC prediction mode. Denoting the CTU size as ctbSize, the virtual buffer ibcBuf has a width of wIbcBuf=128×128 / ctbSize and a height of hIbcBuf=ctbSize. For example, for a CTU size of 128×128, the size of ibcBuf is also 128×128; for a CTU size of 64×64, the size of ibcBuf is 256×64; for a CTU size of 32×32, the size of ibcBuf is 512×32.

[0194] The size of the VPDU is min(ctbSize, 64) in each dimension, Wv = min(ctbSize, 64).

[0195] The virtual IBC buffer ibcBuf is maintained as follows.

[0196] – At the start of decoding each CTU line, flush the entire ibcBuf with an invalid value of -1.

[0197] – At the start of decoding the VPDU (xVPDU, yVPDU) relative to the upper left corner of the picture, set

[0198] ibcBuf[x][y]=-1, where x=xVPDU%wIbcBuf,...,xVPDU%wIbcBuf+wV-1;

[0199] y=yVPDU%ctbSize,...,yVPDU%ctbSize+WV-1.

[0200] - After decoding the CU containing (x, y) relative to the top left corner of the picture, set ibcBuf[x% wIbcBuf][y% ctbSize] = recSample[x][y].

[0201] For a block covering coordinates (x,y), it is valid if the following is true for the block vector bv = (bv[0], bv[1]); otherwise, it is invalid:

[0202] ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] should not be equal to -1.

[0203] Intra-frame block copying in Enhanced Compression Model (ECM)

[0204] In ECM, IBC is improved in the following aspects.

[0205] IBC merger / AMVP list construction

[0206] IBC merge / AMVP list construction is modified as follows:

[0207] ● Only if the IBC merge / AMVP candidate is valid, it can be inserted into the IBC merge / AMVP candidate list.

[0208] ● Top-right, bottom-left and top-left spatial candidates and one pair-wise average candidate may be added to the IBC merge / AMVP candidate list.

[0209] ● Adaptive reordering based on template (ARMC-TM) is applied to the IBC merge list.

[0210] The HMVP table size for IBC is increased to 25. Up to 20 IBC merge candidates are re-ranked together after being derived using full pruning. After re-ranking, the top 6 candidates with the lowest template matching cost are selected as the final candidates in the IBC merge list.

[0211] The candidates for zero vectors used to populate the IBC merge / AMVP list are replaced with a set of BVP candidates located in the IBC reference region. The zero vector is invalid as a block vector in IBC merge mode, and therefore, it is discarded as a BVP in the IBC candidate list.

[0212] Three candidates are located at the nearest corners of the reference region, and three additional candidates are determined in the middle of the three sub-regions (A, B, and C), whose coordinates are determined by the width and height of the current block and the ΔX and ΔY parameters, as Fig. 9 shown.

[0213] IBC with Template Matching

[0214] Template matching is used in IBC for both IBC Merge mode and IBC AMVP mode.

[0215] Compared to the IBC-TM merge list used by the conventional IBC merge mode, the IBC-TM merge list is modified so that candidates are selected according to a pruning method with motion distances between candidates as in the conventional TM merge mode. The ending zero motion implementation is replaced by motion vectors of the left (-W, 0), top (0, -H), and top-left (-W, -H), where W is the width of the current CU and H is the height of the current CU.

[0216] In IBC-TM merge mode, the selected candidates are refined with template matching method before RDO or decoding process.IBC-TM merge mode has been made competitive with regular IBC merge mode and TM merge flag is signaled.

[0217] In IBC-TM AMVP mode, up to 3 candidates are selected from the IBC-TM merge list. Each of those 3 selected candidates is refined using a template matching method and ranked according to their resulting template matching cost. Only the first 2 are then typically considered in the motion estimation process.

[0218] Template matching refinement for both IBC-TM merge and AMVP modes is straightforward because IBC motion vectors are constrained to be (i) integers and (ii) within the reference region, e.g. Figure 8 . Therefore, in IBC-TM merge mode, all refinements are performed with integer precision, and in IBC-TM AMVP mode, refinements are performed with integer or 4-pixel precision depending on the AMVR value. Such refinements only access samples without interpolation. In both cases, the refined motion vectors and the template used in each refinement step must respect the constraints of the reference region.

[0219] IBC Reference Area

[0220] The reference area for IBC extends to the upper two CTU rows. Fig.10 The reference region for encoding CTU(m,n) is shown. Specifically, for the CTU(m,n) to be encoded, the reference region includes CTUs with indices (m-2,n-2)...(W,n-2),(0,n-1)...(W,n-1),(0,n)...(m,n), where W represents the maximum horizontal index within the current tile, slice or picture. This setting ensures that for CTUs of size 128, IBC does not require additional memory in the current ETM platform. The per-sample block vector search (or local search) range is limited horizontally to [-(C<<1),C>>2] and vertically to [-C,C>>2] to accommodate the reference region extension, where C represents the CTU size.

[0221] IBC merge mode with block vector difference

[0222] The IBC merge mode with block vector difference is adopted in ECM. The distance set is {1 pixel, 2 pixels, 4 pixels, 8 pixels, 12 pixels, 16 pixels, 24 pixels, 32 pixels, 40 pixels, 48 ​​pixels, 56 pixels, 64 pixels, 72 pixels, 80 pixels, 88 pixels, 96 pixels, 104 pixels, 112 pixels, 120 pixels, 128 pixels}, and the BVD directions are two horizontal directions and two vertical directions.

[0223] The base candidate is selected from the first five candidates in the reordered IBC merge list. And all possible MBVD refinement positions (20×4) for each base candidate are reordered based on the SAD cost between the template (one row above the current block and one column to the left) and its reference for each refinement position. Finally, the first 8 refinement positions with the lowest template SAD cost are kept as available positions for MBVD index encoding.

[0224] IBC adaption to what the camera captures

[0225] When adapting IBC to the content captured by the camera, the IBC reference range is reduced from 2 CTU rows to 2×128 rows, e.g. Fig.11 As shown in . On the encoder side, in order to reduce complexity, the local search range is set to horizontal [-8, 8] and vertical [-8, 8] centered on the first block vector predictor of the current CU. This encoder modification is not applicable to SCC sequences.

[0226] MVD Sign Prediction

[0227] In this method, possible MVD symbol combinations are ranked according to template matching cost, and the index corresponding to the true MVD symbol is derived and context encoded. At the decoder side, the MVD symbol is derived as follows:

[0228] 1. Analyze the size of MVD components

[0229] 2. Parsing the context-encoded MVD symbol prediction index

[0230] 3. Construct MV candidates by creating combinations between possible signs and absolute MVD values ​​and add them to the MV predictor

[0231] 4. Based on the template matching cost and sorting, the MVD symbol prediction cost of each derived MV is obtained

[0232] 5. Use the MVD symbol prediction index to select the true MVD symbol

[0233] MVD sign prediction is applied to inter-AMVP mode, affine AMVP mode, MMVD mode, and affine MMVD mode.

[0234] Combined Inter-Intra Prediction (CIIP)

[0235] Inter prediction uses signaled motion data to reference temporal information from different pictures to perform motion compensation, which shows significant benefits in video compression. In inter prediction, merge mode is a special type of inter prediction that uses a simpler signaling scheme to derive motion data based on a previously encoded CU. On the other hand, intra prediction tends to provide more accurate spatial predictions when the samples are closer to the reference samples. In order to take advantage of both the inter prediction merge mode and intra prediction, a new merge mode called CIIP mode is designed for CUs that contain at least 64 luma samples and both the CU width and CU height are less than 128. In CIIP mode, a weighted combination of inter prediction merge mode and intra prediction is used for the following predictions. The merge prediction is derived through the inter prediction process for the conventional merge mode, and the intra prediction is derived through the intra prediction process for the planar mode. Then, a weighted averaging process is applied to combine the two predictions. The sum of the prediction weights is equal to 4, and a right shift operation is used after adding the two weighted predictions. Denoted as P CIIP The final forecast of CIIP is formed as follows.

[0236] P CIIP =(W merge *P merge +W intra *P intra +2)>>2 (3)

[0237] Among them, W intra is the weight for intra-frame prediction, which is represented by P intra , W merge is the weight for the combined prediction, which is denoted as P merge , and W intra With W merge The sum of is equal to 4. The weights for intra prediction samples and merged prediction samples are uniform across the CU and are determined based on the number of neighboring intra blocks. If both the top neighbor and the left neighbor are intra coded, then W intra is set to 3, which means that intra prediction is preferred. Otherwise, if only one of these blocks is intra coded, then W intra is set to 2, which means that the same weight is used for both predictions. Otherwise, W intra is set to 1. The weight of CIIP is the same for luma and chroma components. Better coding efficiency can be achieved by weighted averaging one existing merge prediction and another existing intra prediction using a simple weighting process. Moreover, to avoid 2×N intra blocks, when the chroma CB has a width less than 4, only merge prediction is used for chroma CB. To indicate the use of CIIP mode, an additional signal is conditionally signaled to indicate whether CIIP is used when the normal merge mode is selected.

[0238] Combination of CIIP with TIMD and TM

[0239] In CIIP mode, prediction samples are generated by weighting the inter prediction signal using CIIP-TM merge candidate prediction and the intra prediction signal predicted using TIMD derived intra prediction mode. This method is only applied to coding blocks with an area less than or equal to 1024.

[0240] The TIMD derivation method is used to derive intra prediction modes in CIIP. Specifically, the intra prediction mode with the smallest SATD value in the TIMD mode list is selected and mapped to one of the 67 conventional intra prediction modes.

[0241] In addition, it is proposed to modify the weights (wIntra, wInter) for the two tests when the derived intra prediction mode is an angular mode. For near-horizontal mode (2 <= angular mode index < 34), the current block is Fig. 12A For near vertical mode (34 <= angle mode index <= 66), the current block is divided vertically as shown; Fig. 12B The diagram is divided horizontally.

[0242] Table 1 shows (wIntra, wInter) for different sub-blocks.

[0243] Table 1. Modified weights for angle mode.

[0244] Sub-block index (wIntra,wInter) 0 (6,2) 1 (5,3) 2 (3,5) 3 (2,6)

[0245] Using CIIP-TM, a CIIP-TM merge candidate list is constructed for the CIIP-TM mode. The merge candidates are refined by template matching. The CIIP-TM merge candidates are also reordered into regular merge candidates by the ARMC method. The maximum number of CIIP-TM merge candidates is equal to two.

[0246] Multiple Hypothesis Prediction (MHP)

[0247] In the multi-hypothesis inter-frame prediction mode, in addition to the traditional bidirectional prediction signal, one or more additional motion compensated prediction signals are signaled. The resulting overall prediction signal is obtained by weighted superposition on a sample-by-sample basis. bi and the first additional inter-frame prediction signal / hypothesis h3, the resulting prediction signal p3 is obtained as follows:

[0248] p3=(1-α)p bi +αh3

[0249] According to the mapping presented in Table 2, the weighting factor α is specified by a new syntax element add_hyp_weight_idx:

[0250] Table 2. add_hyp_weight_idx and α.

[0251] add_hyp_weight_idx α 0 1 / 4 1 -1 / 8

[0252] Similar to above, more than one additional prediction signal may be used. The resulting overall prediction signal is iteratively accumulated with each additional prediction signal.

[0253] p n+1 =(1-α n+1 ) n +α n+1 h n+1

[0254] The overall prediction signal obtained is used as the final p n (ie with the largest index n) is obtained. Within this mode, up to two additional prediction signals may be used (ie n is limited to 2).

[0255] The motion parameters for each additional prediction hypothesis can be signaled explicitly by specifying the reference index, the motion vector predictor index and the motion vector difference, or implicitly by specifying the merge index.A separate multiple hypothesis merge flag distinguishes these two signaling modes.

[0256] For inter-AMVP mode, MHP is applied only if unequal weights in BCW are selected in bi-prediction mode.

[0257] A combination of MHP and BDOF is possible, however BDOF is only applied to the bidirectional prediction signal part of the prediction signal (ie the ordinary first two hypotheses).

[0258] In the latest video coding standards such as VVC, it is well known that intra-block copying accurately predicts screen content and artificially generated content, where patterns and edges are repeated within the frame. However, the content predicted by intra-block copying is limited to translational transformations, which is achieved by simply copying adjacent pixels. For video content that undergoes more complex geometric transformations (such as stretching, scaling, rotation, and reflection, etc.), current intra-block copying methods may not provide accurate predictions. It is straightforward to extend the capabilities of the traditional IBC mode by predicting not only translational transformations but also more complex transformations.

[0259] Currently, the Block Vector Difference (BVD) symbols in the IBC tool are encoded via bypass mode, and it is straightforward to adapt the MVD symbol prediction technique to BVD symbol prediction, which can reduce the bit overhead of BVD symbol encoding.

[0260] Currently, after adapting the IBC tool to the content captured by the camera, coding blocks encoded in IBC mode can be combined with coding blocks encoded in intra mode or inter mode, which can improve prediction accuracy and improve coding performance.

[0261] Currently, after adapting the IBC tool to the content captured by the camera, the number of block vectors (BVs) in the IBC tool may be increased and the prediction results may be combined, which may improve the prediction accuracy and improve the encoding performance.

[0262] According to the present disclosure, coding tools for intra block copy are improved from various aspects including: multi-model intra block copy, BVD symbol prediction, combined IBC intra / inter prediction and multi-hypothesis IBC prediction.

[0263] Multi-model intra block copy

[0264] Within a piece of video or image content, the presence of different linear transformations can be categorized into two categories:

[0265] Translation transformation

[0266] ●Non-translational transformations, also called affine transformations, include rotation, stretching (scaling in one direction), scaling (scaling in two directions), reflection, etc.

[0267] In general, when aiming to support more complex transformations, higher model complexity is required. Since the diversity of transformations is highly content-dependent, it is desirable to adapt the IBC capabilities to a variety of video content. To this end, a multi-model IBC method is provided to support adaptive linear transformations, which allows IBC to adaptively switch among three models: a 2-parameter model, a 4-parameter model, and a 6-parameter model.

[0268] In summary, the present disclosure provides several methods of adaptively switching the ability of intra block copy methods in order to provide a better trade-off between compression efficiency and complexity, which may include the following aspects:

[0269] 1. Adaptive switching between explicit and implicit derivation of linear transformation vectors.

[0270] 2. Adaptively switch between 2-parameter, 4-parameter or 6-parameter linear transformation models.

[0271] 3. Adaptive switching of decision flows in different modes.

[0272] 4. Adaptive switching of different precisions of linear transformation vectors

[0273] 5. Adaptive switching between different representations of linear transformation vectors.

[0274] Explicit Derivation of Linear Transformation Vectors

[0275] In the explicit derivation method, the linear transform vector is determined at the encoder side and signaled to the decoder side. In order to reduce the size of the signaling bits and potentially reduce the number of signaling bits, the linear transform vector (LTV) may contain two parts: a linear transform vector predictor (LTVP) and a difference (LTVD). The best LTVP is evaluated and selected from the list of LTVP candidates by the encoder, and the index of the selected best LTVP is signaled to the decoder. The selected LTVP is then refined at the encoder side by adding the difference value (called LTVD), and the LTVD value is then compressed and signaled to the decoder side.

[0276] The list of potential LTVP candidates can be constructed by using any combination of the following methods:

[0277] ●Dual parameter LTVP

[0278] ○ Inherit LTVP from adjacent neighbors

[0279] ○ Inherit LTVP from non-adjacent neighbors

[0280] ○ Construct LTVP from adjacent neighbors

[0281] ○ Construct LTVP from adjacent neighbors

[0282] ●4-parameter LTVP

[0283] ○ Inherit LTVP from adjacent neighbors

[0284] ○ Inherit LTVP from non-adjacent neighbors

[0285] ○ Construct LTVP from adjacent neighbors

[0286] ○ Construct LTVP from adjacent neighbors

[0287] ●6-parameter LTVP

[0288] ○ Inherit LTVP from adjacent neighbors

[0289] ○ Inherit LTVP from non-adjacent neighbors

[0290] ○ Construct LTVP from adjacent neighbors

[0291] ○ Construct LTVP from adjacent neighbors

[0292] Zero-fill LTVP

[0293] Fig.13 Examples representing 2-parameter, 4-parameter, and 6-parameter linear transformations are shown in FIG.

[0294] like Fig.14As shown, given a current block with width W and height H, for a specific sample / pixel position at (x, y), the position of its corresponding reference sample / pixel under the 6-parameter model can be expressed as:

[0295]

[0296] Where p1 and p2 are the horizontal and vertical scaling factors, θ is the rotation angle, and c and f are the horizontal and vertical translation displacements. According to equation (3), the displacement vector (DV) from any current sample point (x, y) to its reference sample point (x', y') can be derived as:

[0297]

[0298] In one or more embodiments, the model parameters (a, b, c, d, e, f) in (4) may be represented by the associated LTVs located at the top left (LTV1), top right (LTV2), and bottom left (LTV3) positions, such as Fig.13 In this case, depending on which model is used, the displacement vector for any sample / pixel (x, y) in the current block can be derived as:

[0299] 2-parameter model:

[0300] 4-parameter model:

[0301]

[0302] 6-parameter model:

[0303]

[0304] Given a candidate list of LTVP, one or more candidates from the list are iteratively refined at the encoder side such that the candidate with the minimum sum of absolute transformed differences (SATD) cost between compensated reference samples and original samples is selected.

[0305] In some examples, the candidate list may be reordered according to the two-sided matching cost or the template cost so that the most accurate candidates may be replaced at the front of the list.

[0306] In some examples, the candidate refinement process may be performed similarly to the gradient-based iterative motion estimation process for affine inter prediction mode, as shown in equation (5).

[0307] In some examples, each candidate in the candidate list may be considered as an initial LTV, and an iterative motion estimation process is performed to refine each candidate. The candidate with the smallest SATD cost is selected as the best candidate and the corresponding index is signaled. The refinement result obtained for the best candidate is considered to be LTVD, which is then compressed and signaled to the decoder.

[0308] Alternatively or additionally, the best candidate is determined before the iterative motion estimation process. In one determination method, each LTVP can be directly set to the final LTV, and an affine motion compensation process is performed to find the best candidate with the minimum SATD cost. Once the best candidate is determined, the subsequent refinement process can be the same as the iterative motion estimation process.

[0309] In some examples, when performing a gradient-based iterative motion estimation process, the newly updated LTV is always compared with the best N final candidates from the parent block. Note that if only one candidate of the parent block is iteratively refined, the value of N can be set to 1. Alternatively, the best N final candidates can be enlarged based on the ratio of the size between the current block and the parent block. The parent block is the block containing the current block, that is, the block from which the current block is obtained by partitioning. When the encoder tests the best partition granularity, the encoder will first test the large block (e.g., the parent block) and then further split the current large block into smaller blocks. The encoder can explicitly derive the best motion by performing motion estimation, and then signal the best candidate index and motion difference to the decoder, motion difference = best motion - best candidate, where the candidate is called the motion predictor selected from the candidate list. That is, the motion estimation process can be performed only at the encoder, but the output (motion predictor and motion difference determined by the signaled candidate index) is signaled to the decoder.

[0310] In some examples, at each iteration of the gradient-based motion estimation process, the incremental refinement may be arbitrarily large and cause potentially large biases. In this case, a regularization term may be added to the error function to solve for the best incremental refinement at each iteration.

[0311] In some examples, at each iteration of the gradient-based motion estimation process, if the LTV of a refinement produces a higher SATD cost than the refined LTV from the previous iteration, the incremental refinement is reduced by half before being added.

[0312]

[0313] Wherein, for each sample (x, y) from the current block, error(x, y) represents the sample value error between the compensated reference sample from the i-th iteration and the original sample in the (i+1)-th iteration, g(x, y) is the gradient value at the compensated reference sample from the i-th iteration, and T(x, y) is the transformation matrix from one of the three models.

[0314] When building a list of potential LTVP candidates, LTVs from adjacent neighbors or non-adjacent neighbors may be used for candidate derivation. In one or more embodiments, adjacent and non-adjacent neighboring blocks used for candidate generation may be as follows: Fig.15 and Fig.16 As defined in .

[0315] exist Fig.15 In , only neighbors (adjacent or non-adjacent) with 4-parameter or 6-parameter models are considered valid and used for inheritance candidate generation. In one or more embodiments, the inheritance method can be defined similarly to affine AMVP or merge mode for inter prediction. In another one or more embodiments, the inheritance method can be based on vector concatenation. An example of vector concatenation is in Fig.17 Shown in.

[0316] according to Fig.17 The known vector LTV1 shown in N ,LTV2 N ,LTV3 N ,LTV NC ,W N ,H N ,W C ,H C ), the LTV of the current block can be derived as:

[0317] LTV1 C =LTV1 N +LTV NC

[0318] LTV2 C =W C +LTV NC -W N +LTV2 N

[0319] LTV3 C =H C +LTV NC -H N +LTV3 N

[0320] For inheritance-based LTVP candidate generation, a neighboring block model with higher dimensional parameters may generate the same or lower dimensional parameters for the current block, but may not generate higher dimensional parameters. For example, a 6-parameter model from a neighboring block may generate a 4-parameter or 6-parameter model for the current block, but a 4-parameter model from a neighboring block may not generate a 6-parameter model for the current block.

[0321] exist Fig.16 In , constructing the candidate generation only requires the translation part of each model. In one or more embodiments, the construction method can be similarly defined as affine AMVP or merge mode for inter prediction.

[0322] Implicit Derivation of Linear Transformation Vectors

[0323] In the implicit derivation method, the LTV for the current block is not explicitly signaled, but derived from neighboring blocks. Specifically, in this mode, the LTV of spatially neighboring blocks is used to generate the LTV of the current block. To achieve this goal, an LTV candidate list of limited size is constructed on the decoder side. The encoder can evaluate and select the best candidate index based on a rate-distortion optimization algorithm. The selected candidate index is then signaled to the decoder side. The candidate list (LTV candidate list) can be determined in a manner similar to the determination of the above-mentioned LTVP candidate list.

[0324] In this implicit derivation method, the candidate list may be reordered according to the bilateral matching cost or the template cost so that the most accurate candidate may be replaced to the front of the list.

[0325] In the implicit derivation method, LTV with vector difference (LTVD) can be supported.

[0326] The distance set of LTVD may be predefined, and the LTVD directions may include two horizontal directions and two vertical directions.

[0327] A base candidate may be selected from the first N candidates in the reordered LTV candidate list. And all possible LTVD refinement positions (size of the distance set × size of the LTVD direction) for each base candidate may be reordered based on the SAD cost between the template (e.g., one row above and one column to the left of the current block) and its reference for each refinement position. The first M refinement positions with the lowest template SAD cost may be kept as available positions and thus used for LTVD index encoding.

[0328] Non-translation reference area

[0329] When deriving LVT values ​​at the decoder or encoder side, sub-block based motion compensation may be performed. Since each sub-block of the current block may use a different displacement vector, it is necessary to check whether each corresponding reference block is within the reconstruction region. In one or more embodiments, only four reference blocks corresponding to the four corner sub-blocks (upper left, upper right, lower left, and lower right positions) of the current block may be checked. If any of the four reference blocks is outside the reconstruction region, the entire set of LVT is deemed invalid and the current block falls back to the traditional IBC mode, which only allows a two-parameter model.

[0330] Prediction Process

[0331] In one or more embodiments, the precision of LTV may be limited to integer values. To this end, the output of an explicit or implicit derivation method may be rounded to the nearest integer value.

[0332] In another one or more embodiments, the precision of LTV may be limited to no finer than a certain sub-pixel precision (eg, no higher than 1 / 2 or 1 / 4 pixel precision). When sub-pixel precision LTV is allowed, interpolation filters and pixel padding operations may be required.

[0333] In the case where LTVs have equal values, the current block falls back to the traditional IBC mode, which only allows two-parameter models. If the model has parameters with higher dimensions than two parameters, only two translation parameters are used.

[0334] In another one or more embodiments, it is proposed that the IBC mode never falls back to the traditional mode, but at least uses a 2-parameter model. This is because the IBC fallback mode only derives one MV for the entire CU. As a result, it loses the advantage of sub-block based prediction. Once the current CU selects this IBC fallback mode, the model parameters are propagated to other subsequent CUs with implicit mode. Therefore, the overall coding efficiency is reduced.

[0335] IBC Fallback Mode

[0336] The IBC fallback mode is defined as the traditional IBC mode based on a translation block vector and block (PU or CU) level motion compensation.

[0337] In the multi-model based IBC mode, one of the multiple models may be based on 2 parameters. Fig.13 An example is shown in , where the 2-parameter model contains only one linear transformation vector LTV1.

[0338] In one embodiment, this 2-parameter model is the same as the IBC fallback mode (legacy IBC mode), which includes one translation vector and performs block (PU or CU) level motion compensation.

[0339] In another embodiment, the 2-parameter model is not identical to the IBC fallback mode. In this case, the 2-parameter model may also include a translation vector, but performs sub-block (e.g., 2×2, 4×4, or 8×8 blocks of fixed size) level motion compensation.

[0340] BVD symbol prediction

[0341] In a second aspect of the present disclosure, it is proposed to adapt the MVD symbol prediction technique for BVD symbol prediction. Specifically, possible BVD symbol combinations are sorted according to the template matching cost, and the index corresponding to the real BVD symbol is derived and context encoded. At the decoder side, the BVD symbol is derived as follows:

[0342] 1. Analyze the size of the BVD component

[0343] 2. Parsing the BVD symbol prediction index encoded by the context

[0344] 3. Construct BV candidates by creating combinations between possible signs and BVD absolute values ​​and add them to the BV predictor

[0345] 4. Get the BVD symbol prediction cost of each derived BV based on the template matching cost and sort it

[0346] 5. Use the BVD symbol prediction index to pick the real BVD symbol

[0347] BVD sign prediction is applied to IBC AMVP, IBC Affine AMVP, IBC MMVD, and IBC Affine MMVD modes.

[0348] Combined IBC - Intra / Inter Prediction

[0349] According to one or more embodiments of the present disclosure, a coding block encoded in IBC mode is combined with a coding block encoded in intra mode or inter mode. Different methods can be used to achieve this goal.

[0350] In the first method, it is proposed to combine the coding blocks encoded in the IBC mode with the coding blocks encoded in the intra-frame mode. Various methods can be used in this combination. In one example, similar to the CIIP technology in VVC, the coding blocks encoded in the IBC merge mode are regarded as coding blocks encoded in the inter-frame merge mode and combined with the coding blocks encoded in the planar intra-frame prediction mode. In another example, similar to the combination of CIIP with TIMD and TM merge technology in ECM, the coding blocks encoded in the IBC merge-TM mode are combined with the coding blocks encoded in the intra-frame prediction mode derived from TIMD.

[0351] In the second method, it is proposed to combine a coding block encoded in IBC mode with a coding block encoded in inter-frame mode. Various methods can be used in this combination. In one example, similar to the CIIP technology in VVC, a coding block encoded in IBC merge mode is regarded as a coding block encoded in planar intra mode and combined with a coding block encoded in inter-frame merge mode. In another example, a coding block encoded in IBC merge mode is regarded as a coding block encoded in inter-frame merge mode and combined with a coding block encoded in inter-frame merge mode by equal averaging.

[0352] In the third method, it is proposed to combine the coding blocks encoded in IBC mode with the coding blocks encoded in intra-frame mode and the coding blocks encoded in inter-frame mode. Various methods can be used in this combination. In one example, the coding blocks encoded in IBC mode, the coding blocks encoded in intra-frame mode, and the coding blocks encoded in inter-frame mode are directly combined by equal value averaging. In another example, the coding blocks encoded in IBC mode are first combined separately with the coding blocks encoded in intra-frame mode and inter-frame mode, as presented in the first method and the second method. Then, the individual combination results are combined by equal value averaging.

[0353] Multi-hypothesis IBC prediction

[0354] According to one or more embodiments of the present disclosure, the number of block vectors (BVs) in the IBC tool is increased to 2 or more, and 2 or more hypotheses are combined to obtain the final prediction result. Different methods can be used to achieve this goal.

[0355] In the first method, it is proposed to combine two hypotheses corresponding to two BVs to obtain a final prediction result. Various methods can be used to achieve this goal. In one example, two BVs corresponding to the minimum rate distortion metric and the second minimum rate distortion metric in the IBC AMVP mode are averaged to obtain the final prediction result. In another example, the prediction result corresponding to the IBC AMVP mode and the prediction result corresponding to the IBC merge mode are averaged to obtain the final prediction result.

[0356] In the second method, it is proposed to combine more hypotheses corresponding to more BVs to obtain the final prediction result. Various methods can be used to achieve this goal. In one example, the iterative accumulation method proposed in the multi-hypothesis prediction (MHP) technology is used to obtain the final prediction result. In another example, all BVs corresponding to the minimum, second minimum, third minimum, ... rate-distortion metrics in the IBC AMVP mode are averaged with equal values ​​to obtain the final prediction result.

[0357] Fig.18A computing environment (or computing device) 1610 coupled to a user interface 1660 is shown. The computing environment 1610 may be part of a data processing server. In some embodiments, the computing device 1610 may perform any of the various methods or processes (such as encoding / decoding methods or processes) described above according to various examples of the present disclosure. The computing environment 1610 may include a processor 1620, a memory 1640, and an I / O interface 1650.

[0358] The processor 1620 generally controls the overall operation of the computing environment 1610, such as operations associated with display, data acquisition, data communication, and image processing. The processor 1620 may include one or more processors to execute instructions to perform all or some steps in the above method. In addition, the processor 1620 may include one or more modules that facilitate the interaction between the processor 1620 and other components. The processor may be a central processing unit (CPU), a microprocessor, a single-chip microcomputer, a GPU, etc.

[0359] The memory 1640 is configured to store various types of data to support the operation of the computing environment 1610. The memory 1640 may include predetermined software 1642. Examples of such data include instructions for any application or method operating on the computing environment 1610, video data sets, image data, etc. The memory 1640 may be implemented by using any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0360] I / O interface 1640 provides an interface between processor 1620 and peripheral interface modules such as a keyboard, click wheel, buttons, etc. Buttons may include, but are not limited to, a home button, a start scan button, and a stop scan button. I / O interface 1640 may be coupled to an encoder and a decoder.

[0361] In some embodiments, a non-transitory computer-readable storage medium is also provided, which includes a plurality of programs such as included in the memory 1640, which can be executed by the processor 1620 in the computing environment 1610 for performing the above-mentioned method. For example, the non-transitory computer-readable storage medium can be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0362] The non-transitory computer-readable storage medium has stored therein a plurality of programs for execution by a computing device having one or more processors, wherein the plurality of programs, when executed by the one or more processors, causes the computing device to perform the above-mentioned method for motion prediction.

[0363] In some embodiments, the computing environment 1610 may be implemented using one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above methods.

[0364] Fig.19 is a flow chart illustrating a method for video decoding according to an example of the present disclosure. The method can be implemented for decoding an inter-coded block.

[0365] In step 1901 , the processor 1620 at the decoder side may obtain a current block encoded by IBC based on multi-model IBC, where the multi-model IBC adaptively switches among different models.

[0366] In some examples, the multi-model IBC may adaptively switch among different models, including one of the following methods: the multi-model IBC adaptively switches between explicit derivation of one or more LTVs and implicit derivation of one or more LTVs; the multi-model IBC adaptively switches among a 2-parameter linear transformation model, a 4-parameter linear transformation model, and a 6-parameter linear transformation model; the multi-model IBC adaptively switches among different mode decision streams; the multi-model IBC adaptively switches among different precisions of one or more LTVs; or the multi-model IBC adaptively switches among different representations of one or more LTVs.

[0367] At step 1902, the processor 1620 may obtain one or more linear transformation vectors (LTVs) for a current block.

[0368] In some examples, the processor 1620 at the decoder side may obtain one or more LTVs signaled by the encoder, where at least one of the one or more LTVs may include a linear transform vector predictor (LTVP) and a linear transform vector difference (LTVD).

[0369] In some examples, the processor 1620 on the decoder side may also obtain an LTVP index indicating the best LTVP selected from the LTVP candidate list, obtain an LTVD value corresponding to the LTVP index, and obtain LTV based on the LTVP index and the LTVD value.

[0370] The LTVP candidate list may include various examples. For example, the LTVP candidate list may be a 2-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighbors, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks. In some other examples, the LTVP candidate list may be a 4-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; a 6-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; or a zero-filled LTVP list including one or more zero candidates.

[0371] In some examples, the processor 1620 at the decoder side may obtain a displacement vector from the current sample point to a reference sample point in the current block based on model parameters of different models.

[0372] In some examples, the processor 1620 at the decoder side may reorder one or more LTVP candidates in the LTVP candidate list based on a predetermined cost, where the predetermined cost may include at least one of the following costs: a two-sided matching cost or a template cost.

[0373] In some examples, the decoder-side processor 1620 may refine one or more LTVP candidates in the LTVP candidate list according to a gradient-based iterative motion estimation process.

[0374] In some examples, the processor 1620 on the decoder side may obtain refinements for each initial LTVP candidate by refining each initial LTVP candidate in the LTVP candidate list, obtain an optimal LTVP from the LTVP candidate list based on a sum of absolute transform differences (SATD) cost, wherein the optimal LTVP has a minimum SATD cost, and obtain an LTVD value based on the refinement corresponding to the optimal LTVP.

[0375] In some examples, the processor 1620 on the decoder side may obtain the best LTVP with the minimum SATD cost from the LTVP candidate list by performing a gradient-based iterative motion estimation process, and refine each LTVP candidate in the LTVP candidate list according to the gradient-based iterative motion estimation process.

[0376] In some examples, the decoder-side processor 1620 may obtain a newly updated LTV after performing a gradient-based iterative motion estimation process, and compare the newly updated LTV with one or more best final LTV candidates of the parent block.

[0377] In some examples, the processor 1620 on the decoder side may determine that the number of one or more best final LTV candidates of the parent block is N and N is equal to 1 in response to determining that only one LTVP candidate of the parent block is iteratively refined. In some other examples, the processor 1620 on the decoder side may enlarge the one or more best final LTV candidates based on the size ratio between the current block and the parent block. The parent block is a block containing the current block, that is, a block from which the current block is split. When the encoder tests the best partition granularity, the encoder will first test a large block (e.g., a parent block) and then further split the current large block into smaller blocks. The encoder can explicitly derive the best motion by performing motion estimation, and then transmit the best candidate index and the motion difference to the decoder with a signal, the motion difference = best motion-best candidate, where the candidate is called a motion predictor selected from the candidate list. That is, the motion estimation process can be performed only at the encoder, but the output (the motion predictor and motion difference determined by the candidate index transmitted with the signal) is transmitted to the decoder with a signal.

[0378] In some examples, the decoder-side processor 1620 may apply regularization to the incremental refinement at each iteration.

[0379] In some examples, the decoder-side processor 1620 may reduce incremental refinement in response to determining that the refined LTV produces a higher SATD cost than the refined LTV from a previous iteration.

[0380] In some examples, the processor 1620 at the decoder side may obtain one or more LTVs for the current block based on one or more adjacent neighboring blocks or non-adjacent neighboring blocks of the current block. In addition, the one or more adjacent neighboring blocks or non-adjacent neighboring blocks may include one or more adjacent neighboring blocks or non-adjacent neighboring blocks having a 4-parameter or 6-parameter model for inheritance candidate generation.

[0381] In some examples, the inherited candidate generation can be based on vector concatenation. The following steps can be used to implement vector concatenation: obtain neighboring LTVs of adjacent neighboring blocks or non-adjacent neighboring blocks; obtain a displacement vector between the adjacent neighboring blocks or non-adjacent neighboring blocks and the current block; and obtain the one or more LTVs for the current block based on the adjacent LTVs, the displacement vectors, and the sizes of the adjacent neighboring blocks or non-adjacent neighboring blocks and the current block.

[0382] In some examples, one or more adjacent neighboring blocks or non-adjacent neighboring blocks are used to construct candidate generation in one of the following ways: affine AMVP or merge mode for inter prediction.

[0383] In some other examples, the processor 1620 at the decoder side may derive one or more LTVs for the current block based on one or more neighboring blocks of the current block. For example, the processor 1620 may derive one or more LTVs of the current block based on the LTVs of one or more spatial neighboring blocks.

[0384] In some examples, processor 1620 may obtain an LTV index indicating a best LTV selected from an LTV candidate list, where the LTV candidate list has a predetermined size.

[0385] In some examples, the LTV index may be determined by an encoder based on a rate-distortion optimization algorithm.

[0386] In some examples, processor 1620 may obtain a reordered list of LTV candidates by reordering one or more LTV candidates in the LTV candidate list based on a predetermined cost, where the predetermined cost may include at least one of the following costs: a two-sided matching cost or a template cost.

[0387] In some examples, processor 1620 may also predefine a set of distances of LTV with vector difference (LTVD), select a base LTV candidate from the first N candidates in the reordered list of LTV candidates, where N is a positive integer, and obtain a reordered list of LTVD refined positions by reordering one or more LTVD refined positions of the base LTV candidates based on the SAD cost between a template of a current block and a reference of each refined position.

[0388] In some examples, processor 1620 may also determine one or more LTVD refinement positions based on the size of the distance set and the size of the LTVD direction, and select the first M refinement positions from the reordered list of LTVD refinement positions for LTVD index encoding.

[0389] In some examples, processor 1620 may determine whether a reference block of the current block is within a reconstruction region, determine that one or more LTVs are valid in response to determining that the reference block is within the reconstruction region, and determine that one or more LTVs are invalid in response to determining that the reference block is not within the reconstruction region.

[0390] For example, the processor 1620 may determine whether the reference block of the current block is within the reconstruction region by determining whether four reference blocks corresponding to the four corner blocks of the current block are within the reconstruction region. For example, the four corner blocks (upper left, upper right, lower left, and lower right positions) of the current block may be checked.

[0391] In some examples, processor 1620 may limit the precision of one or more LTVs in one of the following ways: limiting the precision of one or more LTVs to an integer value or limiting the precision of one or more LTVs to no finer than a certain sub-pixel precision.

[0392] In some examples, the processor 1620 may constrain the multi-model IBC to apply only a 2-parameter model in response to determining that two of the one or more LTVs are equal. In some other examples, the processor 1620 may determine a multi-model IBC that adaptively switches among different models, wherein each of the different models has a parameter dimension of not less than 2. For example, the IBC mode never falls back to the traditional mode, but at least uses a 2-parameter model, i.e., the dimension of the parameters of the model is at least 2. That is, the multi-model IBC adaptively switches among different models with parameters of higher dimensions (not less than 2). For example, different models may include a 2-parameter model, a 4-parameter model, a 6-parameter model, etc., and therefore, the dimension of the parameters is 2, 4, or 6.

[0393] In some examples, the 2-parameter model is performed in one of the following ways: the 2-parameter model includes one translation vector and performs block-level motion compensation, or the 2-parameter model includes one translation vector and performs sub-block-level motion compensation.

[0394] Fig. 20 is shown as Fig.19 The method for video decoding shown corresponds to a flow chart of a method for video encoding. The method can be implemented to encode a current block.

[0395] In step 2001, the processor 1620 at the encoder side may obtain one or more linear transformation vectors (LTVs) for a current block.

[0396] In some examples, the multi-model IBC may adaptively switch among different models, including in one of the following ways: the multi-model IBC adaptively switches between explicit derivation of one or more LTVs and implicit derivation of one or more LTVs; the multi-model IBC adaptively switches among a 2-parameter linear transformation model, a 4-parameter linear transformation model, and a 6-parameter linear transformation model; the multi-model IBC adaptively switches among different mode decision streams; the multi-model IBC adaptively switches among different precisions of the one or more LTVs; or the multi-model IBC adaptively switches among different representations of one or more LTVs.

[0397] In step 2002, the processor 1620 may encode a current block according to a multi-model intra block copy (IBC) adaptively switching among different models based on one or more LTVs.

[0398] In some examples, the encoder-side processor 1620 may signal one or more LTVs, where at least one of the one or more LTVs may include a linear transform vector predictor (LTVP) and a linear transform vector difference (LTVD).

[0399] In some examples, the encoder-side processor 1620 may also obtain an LTVP index indicating a best LTVP selection from the LTVP candidate list, obtain an LTVD value corresponding to the LTVP index, and obtain LTV based on the LTVP index and the LTVD value.

[0400] The LTVP candidate list may include various examples. For example, the LTVP candidate list may be a 2-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighbors, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks. In some other examples, the LTVP candidate list may be a 4-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; it may be a 6-parameter LTVP list, which includes one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; or a zero-filled LTVP list including one or more zero candidates.

[0401] In some examples, the processing unit 1620 on the encoder side may obtain a displacement vector from the current sample to a reference sample in the current block based on model parameters of different models.

[0402] In some examples, the processing unit 1620 on the encoder side may reorder one or more LTVP candidates in the LTVP candidate list based on a predetermined cost, where the predetermined cost may include at least one of the following costs: a two-sided matching cost or a template cost.

[0403] In some examples, the encoder-side processor 1620 may refine one or more LTVP candidates in the LTVP candidate list according to a gradient-based iterative motion estimation process.

[0404] In some examples, the processor 1620 on the encoder side may obtain refinements for each initial LTVP candidate by refining each initial LTVP candidate in the LTVP candidate list, obtain an optimal LTVP from the LTVP candidate list based on a sum of absolute transform differences (SATD) cost, wherein the optimal LTVP has a minimum SATD cost, and obtain an LTVD value based on the refinement corresponding to the optimal LTVP.

[0405] In some examples, the processor 1620 on the encoder side may obtain the best LTVP with the minimum SATD cost from the LTVP candidate list by performing a gradient-based iterative motion estimation process, and refine each LTVP candidate in the LTVP candidate list according to the gradient-based iterative motion estimation process.

[0406] In some examples, the encoder-side processor 1620 may obtain a newly updated LTV after performing a gradient-based iterative motion estimation process, and compare the newly updated LTV with one or more best final LTV candidates of the parent block.

[0407] In some examples, the processor 1620 on the encoder side may determine that the number of one or more best final LTV candidates for the parent block is N and N is equal to 1 in response to determining that only one LTVP candidate of the parent block is iteratively refined. In some other examples, the processor 1620 on the encoder side may enlarge the one or more best final LTV candidates based on the size ratio between the current block and the parent block. The parent block is the block containing the current block, that is, the block from which the current block is split. When the encoder tests the best partition granularity, the encoder will first test the large block (e.g., the parent block), and then further split the current large block into smaller blocks.

[0408] In some examples, the encoder-side processor 1620 may apply regularization to the incremental refinement at each iteration.

[0409] In some examples, the encoder-side processor 1620 may reduce incremental refinement in response to determining that the refined LTV produces a higher SATD cost than the refined LTV from a previous iteration.

[0410] In some examples, the processor 1620 at the encoder side may obtain one or more LTVs for the current block based on one or more adjacent neighboring blocks or non-adjacent neighboring blocks of the current block. In addition, the one or more adjacent neighboring blocks or non-adjacent neighboring blocks may include one or more adjacent neighboring blocks or non-adjacent neighboring blocks having a 4-parameter model or a 6-parameter model for inheritance candidate generation.

[0411] In some examples, the inherited candidate generation may be based on vector concatenation. The vector concatenation may be implemented using the following steps: obtaining a neighboring LTV of an adjacent neighboring block or a non-adjacent neighboring block; obtaining a displacement vector between the adjacent neighboring block or the non-adjacent neighboring block and the current block; and obtaining the one or more LTVs for the current block based on the neighboring LTV, the displacement vector, and the size of the adjacent neighboring block or the non-adjacent neighboring block and the current block.

[0412] In some examples, one or more adjacent neighboring blocks or non-adjacent neighboring blocks are used to construct the candidate generation in one of the following ways: affine AMVP or merge mode for inter prediction.

[0413] In some other examples, the processor 1620 on the encoder side may signal an LTV index based on a rate-distortion optimization algorithm, wherein the LTV index indicates a best LTV selected from an LTV candidate list, wherein the LTV candidate list has a predetermined size, and wherein the decoder derives one or more LTVs for the current block based on one or more neighboring blocks of the current block and the LTV index.

[0414] In some examples, processor 1620 may determine whether a reference block of the current block is within a reconstruction region, determine that one or more LTVs are valid in response to determining that the reference block is within the reconstruction region, and determine that one or more LTVs are invalid in response to determining that the reference block is not within the reconstruction region.

[0415] For example, the processor 1620 may determine whether the reference block of the current block is within the reconstruction region by determining whether four reference blocks corresponding to the four corner blocks of the current block are within the reconstruction region. For example, the four corner blocks (upper left, upper right, lower left, and lower right positions) of the current block may be checked.

[0416] In some examples, processor 1620 may limit the precision of one or more LTVs in one of the following ways: limiting the precision of one or more LTVs to an integer value or limiting the precision of one or more LTVs to no finer than a certain sub-pixel precision.

[0417] In some examples, the processor 1620 may constrain the multi-model IBC to apply only a 2-parameter model in response to determining that two of the one or more LTVs are equal. In some other examples, the processor 1620 may determine a multi-model IBC that adaptively switches among different models, wherein each of the different models has a parameter dimension of not less than 2. For example, the IBC mode never falls back to the traditional mode, but at least uses a 2-parameter model, i.e., the dimension of the parameters of the model is at least 2. That is, the multi-model IBC adaptively switches among different models with parameters of higher dimensions (not less than 2). For example, different models may include a 2-parameter model, a 4-parameter model, a 6-parameter model, etc., and therefore, the dimension of the parameters is 2, 4, or 6.

[0418] In some examples, the 2-parameter model is performed in one of the following ways: the 2-parameter model includes one translation vector and performs block-level motion compensation, or the 2-parameter model includes one translation vector and performs sub-block-level motion compensation.

[0419] Fig.21 is a flowchart illustrating a method for video decoding according to an example of the present disclosure.

[0420] In step 2101, the processor 1620 at the decoder side may parse the size of the block vector difference (BVD) component.

[0421] In step 2102, processor 1620 may parse the context-encoded BVD symbol prediction index.

[0422] In step 2103, the processor 1620 may construct a plurality of BV candidates by creating a combination between a BVD sign and a BVD absolute value and adding the combination to a BV predictor.

[0423] In step 2104 , the processor 1620 may derive a BVD symbol prediction cost for each BV candidate based on the template matching cost.

[0424] In step 2105 , the processor 1620 may rank the plurality of BV candidates based on the BVD symbol prediction cost.

[0425] In step 2106, the processor 1620 may derive a BVD symbol prediction index corresponding to the true BVD symbol.

[0426] In some examples, processor 1620 may also apply BVD sign prediction to one of the following modes: intra block copy (IBC) advanced motion vector prediction (AMVP) mode, IBC affine AMVP mode, IBC merge mode with motion vector difference (MMVD) mode, or IBC affine MMVD mode.

[0427] Fig. 22 is shown as Fig.21 The method for video decoding shown corresponds to a flowchart of the method for video encoding.

[0428] In step 2201, the processor 1620 at the encoder side may determine the size of a block vector difference (BVD) component.

[0429] In step 2202, processor 1620 may determine a context-coded BVD symbol prediction index.

[0430] In step 2203, the processor 1620 may construct a plurality of BV candidates by creating a combination between a BVD sign and a BVD absolute value and adding the combination to a BV predictor.

[0431] In step 2204, processor 1620 may determine a BVD symbol prediction cost for each BV candidate based on the template matching cost.

[0432] In step 2205 , the processor 1620 may rank the plurality of BV candidates based on the BVD symbol prediction cost.

[0433] In step 2206, processor 1620 may determine a BVD symbol prediction index corresponding to a true BVD symbol.

[0434] In some examples, processor 1620 may further apply BVD sign prediction to one of the following modes: intra block copy (IBC) advanced motion vector prediction (AMVP) mode, IBC affine AMVP mode, IBC merge mode with motion vector difference (MMVD) mode, or IBC affine MMVD mode.

[0435] Fig.23 is a flowchart illustrating a method for video decoding according to an example of the present disclosure.

[0436] In step 2301, the processor 1620 at the decoder side may obtain a bitstream including a current block, where the current block is composed of coding blocks based on at least one of an intra mode or an inter mode and an intra block copy (IBC) mode.

[0437] In step 2302, the processor 1620 may decode a bitstream based on at least one of the intra mode or the inter mode and the IBC mode.

[0438] In some examples, the bitstream is encoded by combining coding blocks encoded in one of the following ways: combining a first coding block encoded in an IBC merge mode and a second coding block encoded in a planar intra-frame prediction mode; combining a first coding block encoded in an IBC merge TM mode and a second coding block encoded in an intra-frame prediction mode derived from TIMD; combining a first coding block encoded in an IBC merge mode and a second coding block encoded in an inter-frame merge mode, wherein the first coding block and the second coding block are combined in an equal-valued average manner; or combining a first coding block encoded in an IBC mode, a second coding block encoded in an intra-frame mode, and a third coding block encoded in an inter-frame mode. For example, the combination of the first coding block encoded in an IBC mode, the second coding block encoded in an intra-frame mode, and the third coding block encoded in an inter-frame mode can be achieved by combining the first coding block encoded in an IBC mode, the second coding block encoded in an intra-frame mode, and the third coding block encoded in an inter-frame mode in an equal-valued average manner.

[0439] In some examples, the combination of a first coding block encoded in IBC mode, a second coding block encoded in intra-frame mode, and a third coding block encoded in inter-frame mode can be achieved by the following operations: obtaining a first combined coding block by combining the first coding block encoded in IBC mode and the second coding block encoded in intra-frame mode; obtaining a second combined coding block by combining the first coding block encoded in IBC mode and the second coding block encoded in inter-frame mode; and combining the first combined coding block and the second combined coding block in an equal-valued average manner.

[0440] Fig.24 is shown as Fig.23 The method for video decoding shown is a flowchart of a method for video encoding corresponding to that shown.

[0441] In step 2401 , the processor 1620 on the encoder side may encode a current block composed of coding blocks based on at least one of an intra mode or an inter mode and an intra block copy (IBC) mode.

[0442] In step 2402, the processor 1620 may send a bitstream including the current block to a decoder.

[0443] In some examples, a bitstream is encoded by combining coding blocks encoded in one of the following ways: combining a first coding block encoded in an IBC merge mode and a second coding block encoded in a planar intra-frame prediction mode; combining a first coding block encoded in an IBC merge TM mode and a second coding block encoded in an intra-frame prediction mode derived from TIMD; combining a first coding block encoded in an IBC merge mode and a second coding block encoded in an inter-frame merge mode, wherein the first coding block and the second coding block are combined in an equal-valued average manner; or combining the first coding block encoded in an IBC mode, the second coding block encoded in an intra-frame mode, and a third coding block encoded in an inter-frame mode. For example, the combination of the first coding block encoded in an IBC mode, the second coding block encoded in an intra-frame mode, and the third coding block encoded in an inter-frame mode can be achieved by combining the first coding block encoded in an IBC mode, the second coding block encoded in an intra-frame mode, and the third coding block encoded in an inter-frame mode in an equal-valued average manner.

[0444] In some examples, the combination of a first coding block encoded in IBC mode, a second coding block encoded in intra-frame mode, and a third coding block encoded in inter-frame mode can be achieved by the following operations: obtaining a first combined coding block by combining the first coding block encoded in IBC mode and the second coding block encoded in intra-frame mode; obtaining a second combined coding block by combining the first coding block encoded in IBC mode and the second coding block encoded in inter-frame mode; and combining the first combined coding block and the second combined coding block in an equal-valued average manner.

[0445] Fig.25 is a flowchart illustrating a method for video decoding according to an example of the present disclosure.

[0446] In step 2501, the processor 1620 at the decoder side may obtain two or more block vectors (BV) for the current block.

[0447] In step 2502, the processor 1620 may obtain a final intra block copy (IBC) prediction for a current block based on two or more block vectors.

[0448] In some examples, processor 1620 may obtain a first BV corresponding to a minimum rate-distortion matrix in the IBC AMVP mode, obtain a second BV corresponding to a second minimum rate-distortion matrix in the IBC AMVP mode, and obtain a final IBC prediction by equally averaging the first BV and the second BV.

[0449] In some examples, processor 1620 may obtain a first IBC prediction based on a first BV corresponding to the IBC AMVP mode, obtain a second IBC prediction based on a second BV corresponding to the IBC merge mode, and obtain a final IBC prediction by equal-averaging the first IBC prediction and the second IBC prediction.

[0450] In some examples, processor 1620 may use an iterative accumulation method to obtain the final IBC prediction.

[0451] In some examples, processor 1620 may obtain two or more BVs corresponding to different rate-distortion metrics in the IBC AMVP mode, respectively, and obtain a final IBC prediction by equally averaging the two or more BVs.

[0452] Fig.26 is shown as Fig.25 The method for video decoding shown corresponds to a flowchart of the method for video encoding.

[0453] In step 2601, the processor 1620 on the encoder side may obtain two or more block vectors (BV) for a current block.

[0454] In step 2602, the processor 1620 may obtain a final intra block copy (IBC) prediction for a current block based on two or more block vectors.

[0455] In some examples, processor 1620 may obtain a first BV corresponding to a minimum rate-distortion matrix in the IBC AMVP mode, obtain a second BV corresponding to a second minimum rate-distortion matrix in the IBC AMVP mode, and obtain a final IBC prediction by equally averaging the first BV and the second BV.

[0456] In some examples, processor 1620 may obtain a first IBC prediction based on a first BV corresponding to the IBC AMVP mode, obtain a second IBC prediction based on a second BV corresponding to the IBC merge mode, and obtain a final IBC prediction by equal-averaging the first IBC prediction and the second IBC prediction.

[0457] In some examples, processor 1620 may use an iterative accumulation method to obtain the final IBC prediction.

[0458] In some examples, processor 1620 may obtain two or more BVs corresponding to different rate-distortion metrics in the IBC AMVP mode, respectively, and obtain a final IBC prediction by equally averaging the two or more BVs.

[0459] In some examples, a device for video encoding and decoding is provided. The device includes a processor 1620 and a memory 1640 configured to store instructions executable by the processor; wherein the processor is configured to perform the following when executing the instructions: Figure 19-Figure 26 Any method shown.

[0460] In some other examples, a non-transitory computer-readable storage medium is provided having instructions stored therein. When the instructions are executed by the processor 1620, the instructions cause the processor to perform the following steps: Figure 19-Figure 26 In one example, the plurality of programs may be executed by a processor 1620 in a computing environment 1610 to (e.g., Figure 1G The video encoder 20 in the computing environment 1610 receives a bitstream or data stream containing encoded video information (e.g., video blocks representing encoded video frames and / or one or more associated syntax elements, etc.), and can also be executed by the processor 1620 in the computing environment 1610 to perform the decoding method as described above according to the received bitstream or data stream. In another example, the multiple programs can be executed by the processor 1620 in the computing environment 1610 to perform the encoding method as described above to encode the video information (e.g., video blocks representing video frames and / or one or more associated syntax elements, etc.) into a bitstream or data stream, and can also be executed by the processor 1620 in the computing environment 1610 to send a bitstream or data stream (e.g., to Figure 2B Alternatively, the non-transitory computer-readable storage medium may store therein a bitstream or data stream including encoded video information (e.g., video blocks representing encoded video frames and / or associated one or more syntax elements, etc.), the encoded video information being encoded by an encoder (e.g., Figure 1G The video encoder 20 in FIG. 1 generates a video signal for a decoder (eg, Figure 2B The video decoder 30 in the example is used when decoding video data. The non-transitory computer-readable storage medium may be, for example, a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, or the like.

[0461] In view of the specification and practice of the present disclosure disclosed herein, other examples of the present disclosure will be apparent to those skilled in the art. This application is intended to cover any variation, use or modification of the present disclosure that follows the general principles of the present disclosure, and includes deviations from the present disclosure that fall within known or customary practices in the art. It is intended that the specification and examples be considered exemplary only.

[0462] It should be understood that the present disclosure is not limited to the exact examples described above and shown in the accompanying drawings, and that various modifications and changes may be made without departing from the scope thereof.

Claims

1. A method for video decoding, comprising: Obtaining, by a decoder, a current block encoded by IBC based on multi-model intra block copy (IBC), wherein the multi-model IBC adaptively switches among different models; and One or more linear transformation vectors LTV for the current block are obtained by the decoder.

2. The method according to claim 1, wherein: The multi-model IBC adaptively switches among the different models including at least one of the following ways: The multi-model IBC adaptively switches between explicit derivation of the one or more LTVs and implicit derivation of the one or more LTVs; The multi-model IBC adaptively switches among a 2-parameter linear transformation model, a 4-parameter linear transformation model, and a 6-parameter linear transformation model; The multi-model IBC adaptively switches among different mode decision flows; The multi-model IBC adaptively switches among different accuracies of the one or more LTVs; or The multi-model IBC adaptively switches among different representations of the one or more LTVs.

3. The method according to claim 1, further comprising: The one or more LTVs signaled by the encoder are obtained by the decoder, wherein at least one of the one or more LTVs comprises a linear transformed vector predictor LTVP and a linear transformed vector difference LTVD.

4. The method according to claim 3, further comprising: Obtaining, by the decoder, an LTVP index indicating a best LTVP selected from a LTVP candidate list; as well as Obtaining, by the decoder, an LTVD value corresponding to the LTVP index; and The LTV is obtained by the decoder based on the LTVP index and the LTVD value.

5. The method according to claim 4, wherein: The LTVP candidate list includes at least one of the following lists: 2-parameter LTVP list, including one or more inherited LTVPs from adjacent neighbor blocks, one or more inherited LTVPs from non-adjacent neighbors, one or more constructed LTVPs from adjacent neighbor blocks, and one or more constructed LTVPs from non-adjacent neighbor blocks; 4-parameter LTVP list, including one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; 6-parameter LTVP list, including one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; or Zero-filled LTVP list, including one or more zero candidates.

6. The method according to claim 1, further comprising: The decoder obtains a displacement vector from a current sample point to a reference sample point in the current block based on the model parameters of the different models.

7. The method according to claim 4, further comprising: The decoder reorders one or more LTVP candidates in the LTVP candidate list based on a predetermined cost, wherein the predetermined cost comprises at least one of the following costs: a two-sided matching cost or a template cost.

8. The method according to claim 4, further comprising: One or more LTVP candidates in the LTVP candidate list are refined by the decoder according to a gradient-based iterative motion estimation process.

9. The method according to claim 8, further comprising: The decoder obtains a refinement for each initial LTVP candidate by refining each initial LTVP candidate in the LTVP candidate list; obtaining, by the decoder, the best LTVP from the LTVP candidate list based on a sum of absolute transform differences (SATD) cost, wherein the best LTVP has a minimum SATD cost; and The LTVD value is obtained by the decoder based on the refinement corresponding to the optimal LTVP.

10. The method according to claim 8, further comprising: Obtaining, by the decoder, the best LTVP with the minimum SATD cost from the LTVP candidate list by performing the gradient-based iterative motion estimation process; as well as Each LTVP candidate in the LTVP candidate list is refined by the decoder according to the gradient-based iterative motion estimation process.

11. The method according to claim 8, further comprising: Obtaining a newly updated LTV by the decoder after performing the gradient-based iterative motion estimation process; as well as The newly updated LTV is compared by the decoder to one or more best final LTV candidates of the parent block.

12. The method according to claim 11, wherein: The number of the one or more best final LTV candidates of the parent block is N, and N is a positive integer; Wherein, the method further comprises: In response to determining that only one LTVP candidate of the parent block is iteratively refined, determining, by the decoder, that N is equal to 1; or The one or more best final LTV candidates are enlarged based on a size ratio between the current block and the parent block.

13. The method according to claim 8, further comprising: Regularization is applied by the decoder to the incremental refinement at each iteration.

14. The method according to claim 13, further comprising: In response to determining that the LTV of a refinement produces a higher SATD cost than the LTV of a refinement from a previous iteration, the incremental refinement is reduced by the decoder.

15. The method according to claim 1, further comprising: The one or more LTVs for the current block are obtained by the decoder based on one or more adjacent neighboring blocks or non-adjacent neighboring blocks of the current block.

16. The method according to claim 15, wherein: The one or more adjacent neighboring blocks or non-adjacent neighboring blocks include one or more adjacent neighboring blocks or non-adjacent neighboring blocks having a 4-parameter model or a 6-parameter model for inheritance candidate generation.

17. The method according to claim 16, wherein: The inheritance candidate generation is based on vector concatenation.

18. The method according to claim 17, wherein: The vector concatenation comprises: Obtaining, by the decoder, adjacent LTVs of adjacent neighboring blocks or non-adjacent neighboring blocks; Obtaining, by the decoder, a displacement vector between the adjacent neighboring block or the non-adjacent neighboring block and the current block; and The one or more LTVs for the current block are obtained by the decoder based on the neighboring LTVs, the displacement vectors, and sizes of the neighboring or non-neighboring neighboring blocks and the current block.

19. The method according to claim 16, wherein: The one or more adjacent neighboring blocks or non-adjacent neighboring blocks are used to construct candidate generation in one of the following ways: affine AMVP or merge mode for inter prediction.

20. The method of claim 1, further comprising: The one or more LTVs for the current block are derived by the decoder based on one or more neighboring blocks of the current block.

21. The method according to claim 20, further comprising: The one or more LTVs for the current block are derived by the decoder based on LTVs of one or more spatially neighboring blocks.

22. The method according to claim 21, further comprising: An LTV index indicating an optimal LTV selected from an LTV candidate list is obtained by the decoder, wherein the LTV candidate list has a predetermined size.

23. The method according to claim 22, wherein: The LTV index is determined by the encoder based on a rate-distortion optimization algorithm.

24. The method of claim 22, further comprising: The decoder obtains a reordered list of LTV candidates by reordering one or more LTV candidates in the LTV candidate list based on a predetermined cost, wherein the predetermined cost comprises at least one of the following costs: a two-sided matching cost or a template cost.

25. The method according to claim 24, further comprising: A set of distances of LTV with vector difference (LTVD) is predefined by the decoder; as well as Selecting, by the decoder, a base LTV candidate from first N candidates in the reordered list of LTV candidates, where N is a positive integer; as well as A reordered list of LTVD refinement positions is obtained by the decoder by reordering one or more LTVD refinement positions of the base LTV candidate based on a SAD cost between a template of the current block and a reference of each refinement position.

26. The method according to claim 25, further comprising: Determining, by the decoder, the one or more LTVD refinement positions based on the size of the distance set and the size of the LTVD direction; or The first M refinement positions are selected by the decoder from the reordered list of LTVD refinement positions for LTVD index encoding.

27. The method of claim 1, further comprising: Determining, by the decoder, whether a reference block of the current block is within a reconstruction region; In response to determining that the reference block is within the reconstruction region, determining, by the decoder, that the one or more LTVs are valid; as well as In response to determining that the reference block is not within the reconstruction region, determining, by the decoder, that the one or more LTVs are invalid.

28. The method according to claim 27, wherein: Determining whether the reference block of the current block is included in the reconstruction area: It is determined whether four reference blocks corresponding to four corner sub-blocks of the current block are within the reconstruction area.

29. The method of claim 1, further comprising: The accuracy of the one or more LTVs is limited by the decoder in one of the following ways: restricting the precision of the one or more LTVs to integer values; or The precision of the one or more LTVs is limited to no finer than a certain sub-pixel precision.

30. The method of claim 1, further comprising: In response to determining that two of the one or more LTVs are equal, constraining, by the decoder, the multi-model IBC to apply only a 2-parameter model; or The multi-model IBC that adaptively switches among the different models is determined by the decoder, wherein each of the different models has a dimension of parameters not less than 2.

31. The method of claim 30, wherein the 2-parameter model operates in one of the following ways: The 2-parameter model includes a translation vector and performs block-level motion compensation; or The 2-parameter model includes a translation vector and performs sub-block level motion compensation.

32. A method for video decoding, comprising: The size of the block vector difference BVD component is parsed by the decoder; Parsing, by the decoder, a context-encoded BVD symbol prediction index; constructing, by the decoder, a plurality of BV candidates by creating combinations between BVD symbols and BVD absolute values ​​and adding the combinations to a BV predictor; deriving, by the decoder, a BVD symbol prediction cost for each BV candidate based on the template matching cost; sorting, by the decoder, the plurality of BV candidates based on the BVD symbol prediction cost; as well as A BVD symbol prediction index corresponding to a true BVD symbol is derived by the decoder.

33. The method of claim 32, further comprising: BVD sign prediction is applied by the decoder in one of the following modes: Intra Block Copy IBC Advanced Motion Vector Prediction AMVP mode, IBC Affine AMVP mode, IBC Merge Mode with Motion Vector Difference MMVD mode, or IBC Affine MMVD mode.

34. A method for video decoding, comprising: Obtaining, by a decoder, a bitstream including a current block, wherein the current block is composed of coding blocks based on at least one of an intra mode or an inter mode and an intra block copy (IBC) mode; as well as The decoder decodes the bitstream based on the at least one of the intra mode or the inter mode and the IBC mode.

35. The method of claim 34, wherein: The bitstream is encoded by combining coding blocks encoded in one of the following ways: Combining a first coding block encoded in an IBC merge mode and a second coding block encoded in a planar intra prediction mode; Combining a first coded block encoded in the IBC merged TM mode and a second coded block encoded in the TIMD derived intra prediction mode; Combining a first coding block encoded in an IBC merge mode and a second coding block encoded in an inter-frame merge mode, wherein the first coding block and the second coding block are combined in an equal-valued average manner; or A first coded block encoded in the IBC mode, a second coded block encoded in the intra mode, and a third coded block encoded in the inter mode are combined.

36. The method of claim 35, wherein: Combining a first coded block encoded in IBC mode, a second coded block encoded in intra mode, and a third coded block encoded in inter mode comprises: A first coded block coded in the IBC mode, a second coded block coded in the intra mode, and a third coded block coded in the inter mode are combined in an equal-value average manner.

37. The method of claim 35, wherein: Combining a first coded block encoded in IBC mode, a second coded block encoded in intra mode, and a third coded block encoded in inter mode comprises: Obtaining a first combined coded block by combining a first coded block coded in the IBC mode and a second coded block coded in the intra mode; Obtaining a second combined coded block by combining a first coded block coded in the IBC mode and a second coded block coded in the inter-frame mode; and The first combined coded block and the second combined coded block are combined in an equal-valued average manner.

38. A method for video decoding, comprising: Obtaining two or more block vectors BV for the current block by the decoder; as well as A final intra block copy (IBC) prediction for the current block is obtained by the decoder based on the two or more block vectors.

39. The method of claim 38, further comprising: Obtaining, by the decoder, a first BV corresponding to a minimum rate-distortion matrix in an IBC AMVP mode; Obtaining, by the decoder, a second BV corresponding to a second minimum rate-distortion matrix in the IBC AMVP mode; as well as The final IBC prediction is obtained by the decoder by equally averaging the first BV and the second BV.

40. The method of claim 38, further comprising: Obtaining, by the decoder, a first IBC prediction based on a first BV corresponding to an IBC AMVP mode; Obtaining, by the decoder, a second IBC prediction based on a second BV corresponding to the IBC merge mode; as well as The final IBC prediction is obtained by the decoder by equally averaging the first IBC prediction and the second IBC prediction.

41. The method of claim 38, further comprising: The final IBC prediction is obtained by the decoder using an iterative accumulation method.

42. The method of claim 38, further comprising: obtaining, by the decoder, the two or more BVs respectively corresponding to different rate-distortion metrics in an IBC AMVP mode; as well as The final IBC prediction is obtained by the decoder by equally averaging the two or more BVs.

43. A method for video encoding, comprising: Obtaining, by the encoder, one or more linear transformation vectors LTV for the current block; as well as The current block is encoded by the encoder and based on the one or more LTVs based on a multi-model intra block complex (IBC) that adaptively switches among different models.

44. The method of claim 43, wherein: The multi-model IBC adaptively switches among the different models including at least one of the following ways: The multi-model IBC adaptively switches between explicit derivation of the one or more LTVs and implicit derivation of the one or more LTVs; The multi-model IBC adaptively switches among a 2-parameter linear transformation model, a 4-parameter linear transformation model, and a 6-parameter linear transformation model; The multi-model IBC adaptively switches among different mode decision flows; The multi-model IBC adaptively switches among different accuracies of the one or more LTVs; or The multi-model IBC adaptively switches among different representations of one or more LTVs.

45. The method of claim 43, further comprising: The one or more LTVs are signaled by the encoder, wherein at least one of the one or more LTVs comprises a linear transformed vector predictor LTVP and a linear transformed vector difference LTVD.

46. ​​The method of claim 43, further comprising: Obtaining, by the encoder, an LTVP index indicating a best LTVP selected from a LTVP candidate list; as well as Obtaining, by the encoder, an LTVD value corresponding to the LTVP index; and The LTV is obtained by the encoder based on the LTVP index and the LTVD value.

47. The method of claim 46, wherein: The LTVP candidate list includes at least one of the following lists: 2-parameter LTVP list, including one or more inherited LTVPs from adjacent neighbor blocks, one or more inherited LTVPs from non-adjacent neighbors, one or more constructed LTVPs from adjacent neighbor blocks, and one or more constructed LTVPs from non-adjacent neighbor blocks; 4-parameter LTVP list, including one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; 6-parameter LTVP list, including one or more inherited LTVPs from adjacent neighboring blocks, one or more inherited LTVPs from non-adjacent neighboring blocks, one or more constructed LTVPs from adjacent neighboring blocks, and one or more constructed LTVPs from non-adjacent neighboring blocks; or Zero-filled LTVP list, including one or more zero candidates.

48. The method of claim 43, further comprising: The encoder obtains a displacement vector from a current sample point to a reference sample point in the current block based on the model parameters of the different models.

49. The method of claim 46, further comprising: The encoder reorders one or more LTVP candidates in the LTVP candidate list based on a predetermined cost, wherein the predetermined cost comprises at least one of the following costs: a bilateral matching cost or a template cost.

50. The method of claim 46, further comprising: One or more LTVP candidates in the LTVP candidate list are refined by the encoder according to a gradient-based iterative motion estimation process.

51. The method of claim 50, further comprising: The encoder obtains a refinement for each initial LTVP candidate by refining each initial LTVP candidate in the LTVP candidate list; Obtaining, by the encoder, the best LTVP from the LTVP candidate list based on a sum of absolute transform differences (SATD) cost, wherein the best LTVP has a minimum SATD cost; and The LTVD value is obtained by the encoder based on the refinement corresponding to the optimal LTVP.

52. The method of claim 50, further comprising: Obtaining, by the encoder, the best LTVP with the minimum SATD cost from the LTVP candidate list by performing the gradient-based iterative motion estimation process; as well as Each LTVP candidate in the LTVP candidate list is refined by the encoder based on the gradient-based iterative motion estimation process.

53. The method of claim 50, further comprising: Obtaining a newly updated LTV by the encoder after performing the gradient-based iterative motion estimation process; as well as The newly updated LTV is compared by the encoder to one or more best final LTV candidates for the parent block.

54. The method of claim 53, wherein: The number of the one or more best final LTV candidates of the parent block is N, and N is a positive integer; Wherein, the method further comprises: In response to determining that only one LTVP candidate of the parent block is iteratively refined, determining, by the encoder, that N is equal to 1; or The one or more best final LTV candidates are enlarged based on a size ratio between the current block and the parent block.

55. The method of claim 50, further comprising: Regularization is applied by the encoder to the incremental refinement at each iteration.

56. The method of claim 55, further comprising: The incremental refinement is reduced by the encoder in response to determining that the LTV of a refinement produces a higher SATD cost than the LTV of a refinement from a previous iteration.

57. The method of claim 43, further comprising: The one or more LTVs for the current block are obtained by the encoder based on one or more adjacent neighboring blocks or non-adjacent neighboring blocks of the current block.

58. The method of claim 57, wherein: The one or more adjacent neighboring blocks or non-adjacent neighboring blocks include one or more adjacent neighboring blocks or non-adjacent neighboring blocks having a 4-parameter or 6-parameter model for inheritance candidate generation.

59. The method of claim 58, wherein: The inheritance candidate generation is based on vector concatenation.

60. The method of claim 59, wherein: The vector concatenation comprises: Obtaining, by the encoder, a neighboring LTV of an adjacent neighboring block or a non-adjacent neighboring block; Obtaining, by the encoder, a displacement vector between the adjacent neighboring block or the non-adjacent neighboring block and the current block; and The one or more LTVs for the current block are obtained by the encoder based on the neighboring LTVs, the displacement vectors, and sizes of the neighboring or non-neighboring neighboring blocks and the current block.

61. The method of claim 58, wherein: The one or more adjacent neighboring blocks or non-adjacent neighboring blocks are used to construct candidate generation in one of the following ways: affine AMVP or merge mode for inter prediction.

62. The method of claim 43, further comprising: An LTV index is signaled by the encoder based on a rate-distortion optimization algorithm, wherein the LTV index indicates a best LTV selected from an LTV candidate list, wherein the LTV candidate list has a predetermined size, and wherein the decoder derives the one or more LTVs for the current block based on one or more neighboring blocks of the current block and the LTV index.

63. The method of claim 43, further comprising: Determining, by the encoder, whether a reference block of the current block is within a reconstruction region; In response to determining that the reference block is within the reconstruction region, determining, by the encoder, that the one or more LTVs are valid; as well as In response to determining that the reference block is not within the reconstruction region, the one or more LTVs are determined by the encoder to be invalid.

64. The method of claim 63, wherein: Determining whether the reference block of the current block is included in the reconstruction area: It is determined whether four reference blocks corresponding to four corner sub-blocks of the current block are within the reconstruction area.

65. The method of claim 43, further comprising: The accuracy of the one or more LTVs is limited by the encoder in one of the following ways: limiting, by the encoder, the precision of the one or more LTVs to integer values; or The precision of the one or more LTVs is constrained by the encoder to be no finer than a certain sub-pixel precision.

66. The method of claim 43, further comprising: In response to determining that two of the one or more LTVs are equal, constraining, by the encoder, the multi-model IBC to apply only a 2-parameter model; or The multi-model IBC that adaptively switches among the different models is determined by the encoder, wherein each of the different models has a dimension of parameters not less than 2.

67. The method of claim 66, wherein: The 2-parameter model is implemented in one of the following ways: The 2-parameter model includes a translation vector and performs block-level motion compensation; or The 2-parameter model includes a translation vector and performs sub-block level motion compensation.

68. A method for video encoding, comprising: The encoder encodes a current block formed by combining coding blocks based on at least one of an intra mode or an inter mode and an intra block copy (IBC) mode; as well as A bitstream including the current block is sent by the encoder to a decoder.

69. The method of claim 68, wherein: The bitstream is encoded by combining the coding blocks encoded in one of the following ways: Combining a first coding block encoded in an IBC merge mode and a second coding block encoded in a planar intra prediction mode; Combining a first coding block encoded in the IBC merged TM mode with a second coding block encoded in the TIMD derived intra prediction mode; Combining a first coding block encoded in an IBC merge mode and a second coding block encoded in an inter-frame merge mode, wherein the first coding block and the second coding block are combined in an equal-valued average manner; or A first coded block encoded in the IBC mode, a second coded block encoded in the intra mode, and a third coded block encoded in the inter mode are combined.

70. The method of claim 69, wherein: Combining a first coded block encoded in IBC mode, a second coded block encoded in intra mode, and a third coded block encoded in inter mode comprises: A first coding block encoded in the IBC mode, a second coding block encoded in the intra-frame mode, and a third coding block encoded in the inter-frame mode are combined in an equal-value average manner.

71. The method of claim 69, wherein: Combining a first coded block encoded in IBC mode, a second coded block encoded in intra mode, and a third coded block encoded in inter mode comprises: Obtaining a first combined coded block by combining a first coded block coded in the IBC mode and a second coded block coded in the intra mode; Obtaining a second combined coded block by combining a first coded block coded in the IBC mode and a second coded block coded in the inter-frame mode; and The first combined coded block and the second combined coded block are combined in an equal-valued average manner.

72. A method for video encoding, comprising: Obtaining, by the encoder, two or more block vectors BV for the current block; as well as A final intra block copy (IBC) prediction for the current block is obtained by the encoder based on the two or more block vectors.

73. The method of claim 72, further comprising: Obtaining, by the encoder, a first BV corresponding to a minimum rate-distortion matrix in an IBC AMVP mode; Obtaining, by the encoder, a second BV corresponding to a second minimum rate-distortion matrix in the IBC AMVP mode; as well as The final IBC prediction is obtained by the encoder by equally averaging the first BV and the second BV.

74. The method of claim 72, further comprising: Obtaining, by the encoder, a first IBC prediction based on a first BV corresponding to an IBC AMVP mode; Obtaining, by the encoder, a second IBC prediction based on a second BV corresponding to the IBC merge mode; as well as The final IBC prediction is obtained by the encoder by equally averaging the first IBC prediction and the second IBC prediction.

75. The method of claim 72, further comprising: The final IBC prediction is obtained by the encoder using an iterative accumulation method.

76. The method of claim 72, further comprising: Obtaining, by the encoder, the two or more BVs respectively corresponding to different rate-distortion metrics in an IBC AMVP mode; as well as The final IBC prediction is obtained by the encoder by equally averaging the two or more BVs.

77. A method for video encoding, comprising: The size of the block vector difference BVD component is determined by the encoder; Determining, by the encoder, a BVD symbol prediction index to be context-coded; constructing, by the encoder, a plurality of BV candidates by creating combinations between BVD signs and BVD absolute values ​​and adding the combinations to a BV predictor; Determining, by the encoder, a BVD symbol prediction cost for each BV candidate based on the template matching cost; sorting, by the encoder, the plurality of BV candidates based on the BVD symbol prediction cost; as well as The encoder determines a BVD symbol prediction index corresponding to a true BVD symbol.

78. The method of claim 77, further comprising: BVD sign prediction is applied by the encoder in one of the following modes: Intra Block Copy IBC Advanced Motion Vector Prediction AMVP mode, IBC Affine AMVP mode, IBC Merge Mode with Motion Vector Difference MMVD mode, or IBC Affine MMVD mode.

79. An apparatus for video decoding, comprising: one or more processors; as well as a memory coupled to the one or more processors and configured to store instructions executable by the one or more processors, Wherein, when executing the instructions, the one or more processors are configured to perform the method according to any one of claims 1-42.

80. An apparatus for video encoding, comprising: one or more processors; as well as a memory coupled to the one or more processors and configured to store instructions executable by the one or more processors, Wherein, when executing the instructions, the one or more processors are configured to perform the method according to any one of claims 43-78.

81. A non-transitory computer-readable storage medium for storing computer-executable instructions, which, when executed by one or more computer processors, cause the one or more computer processors to receive a bitstream and perform the method of any one of claims 1-42 based on the bitstream.

82. A non-transitory computer-readable storage medium for storing computer-executable instructions, which, when executed by one or more computer processors, cause the one or more computer processors to perform the method according to any one of claims 43-78 to encode the current block into a bitstream and send the bitstream.

83. A non-transitory computer-readable storage medium for storing a bitstream to be decoded by the method according to any one of claims 1-42.

84. A non-transitory computer-readable storage medium for storing a bitstream generated by the method of any one of claims 43-78.

Images