Method and device for video processing and medium

Abstract

Embodiments of the present disclosure provide a solution for video processing. A method for video processing is proposed. In the method, for a conversion between a current video block of the video and a bitstream of the video, a time domain block vector (BV) candidate for the current video block is determined from a time domain position in a co-located picture of the current video block. The conversion is performed based on the time domain BV candidates. At least one of a BV or a flag of an intra block copy with local illumination compensation (IBC-LIC) is inherited from a time domain location.

Description

Technical Field

[0001] The embodiments of this disclosure generally relate to video processing techniques, and more specifically, to temporal block vector (BV) candidates. Background Technology

[0002] Today, digital video capabilities are being applied to all aspects of people's lives. Various video compression technologies have been proposed for video encoding / decoding, such as MPEG-2, MPEG-4, ITU-TH.263, ITU-TH.264 / MPEG-4 Part 10 Advanced Video Codec (AVC), ITU-TH.265 High Efficiency Video Codec (HEVC) standard, and Multifunctional Video Codec (VVC) standard. However, the overall expectation is to further improve the encoding and decoding efficiency of video encoding and decoding technologies. Summary of the Invention

[0003] Embodiments of this disclosure provide a solution for video processing.

[0004] In a first aspect, a method for video processing is proposed. This method includes: for a conversion between a current video block and the video bitstream, determining a temporal block vector (BV) candidate for the current video block from its temporal position in a co-located image of the current video block; and performing a conversion based on the temporal BV candidate, wherein at least one of the BV or the flag of Intra-Block Copy with Local Illumination Compensation (IBC-LIC) is inherited from the temporal position. In this way, either the BV or the IBC-LIC flag can be inherited. Therefore, encoding / decoding efficiency and effectiveness can be improved.

[0005] In a second aspect, an apparatus for video processing is provided. The apparatus includes a processor and a non-transitory memory having instructions thereon. When executed by the processor, the instructions cause the processor to perform the method according to the first aspect of this disclosure.

[0006] In a third aspect, a non-transitory computer-readable storage medium is proposed. This non-transitory computer-readable storage medium stores instructions that cause a processor to perform the method according to the first aspect of this disclosure.

[0007] In a fourth aspect, another non-transitory computer-readable recording medium is proposed. This non-transitory computer-readable recording medium stores a bitstream of video generated by a method performed by an apparatus for video processing. The method includes: determining a temporal block vector (BV) candidate for the current video block from its temporal location in a co-located image of the current video block; and generating a bitstream based on the temporal BV candidate, wherein at least one of the following flags—BV or intra-block copy with local illumination compensation (IBC-LIC)—is inherited from the temporal location.

[0008] In a fifth aspect, a method for storing a bitstream of video is proposed. The method includes: determining a temporal block vector (BV) candidate for the current video block from its temporal position in a co-located image of the current video block; generating a bitstream based on the temporal BV candidate; and storing the bitstream in a non-transitory computer-readable recording medium, wherein at least one of the following flags—either the BV or an intra-frame block copy with local illumination compensation (IBC-LIC)—is inherited from the temporal position.

[0009] The present invention is provided to present, in a simplified form, the selection of concepts further described below in the detailed description. The present invention is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

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

[0011] Figure 1 A block diagram illustrating an example video codec system according to some embodiments of the present disclosure is shown;

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

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

[0014] Figure 4 The spatial proximity locations used in IBC vector prediction are shown;

[0015] Figure 5 The current CTU processing order and its available reference samples in the current and left CTUs are shown;

[0016] Figure 6 This shows the spatial proximity locations used in the construction of the IBC Merge / AMVP list;

[0017] Figure 7 The filling candidates for replacing the zero vector in the IBC list are shown;

[0018] Figure 8 The IBC reference area is shown, depending on the current CU location;

[0019] Figure 9This shows the reference region for IBC when CTU(m,n) is encoded and decoded. Blue blocks represent the current CTU; green blocks represent the reference region; and white blocks represent invalid reference regions.

[0020] Figure 10A A diagram showing the BV adjustment for horizontal flipping is provided;

[0021] Figure 10B A diagram illustrating the BV adjustment for vertical flipping is shown;

[0022] Figure 11 The intra-frame template matching search region used is shown;

[0023] Figure 12 The use of the IntraTMP block vector for IBC blocks is shown;

[0024] Figure 13A An example of a candidate list of IBC block vectors that only contain IBC block vectors is shown;

[0025] Figure 13B An example of a candidate list of IBC block vectors that contains both IBC block vectors and IntraTMP block vectors is shown;

[0026] Figure 14 The template and its reference sample points in the reference image are shown;

[0027] Figure 15 The template of the block with sub-block motion information using the current block and the reference sample points of the template are shown;

[0028] Figure 16 The locations of the spatial merge candidates are shown;

[0029] Figure 17 Candidate pairs considered for redundancy checks in the spatial merge candidate are shown;

[0030] Figure 18 An illustration of motion vector scaling for temporal Merge candidates is shown;

[0031] Figure 19 The candidate positions of time-domain Merge candidates C0 and C1 are shown;

[0032] Figure 20 The spatial neighbor block used to derive spatial merge candidates is shown;

[0033] Figure 21A This shows the spatial neighboring block used by ATVMP;

[0034] Figure 21BThis demonstrates how to derive the motion field of a sub-CU by applying motion displacements from spatial neighbors and scaling motion information from the corresponding co-located sub-CUs.

[0035] Figure 22A Candidate locations for the airspace candidate are shown;

[0036] Figure 22B The candidate locations for the time-domain candidates are shown;

[0037] Figure 23 The candidate positions for time-domain BV candidates are shown, where the spatial domain can be left, top, upper right, lower left, or upper left.

[0038] Figure 24 Candidate positions for time-domain BV candidates are shown;

[0039] Figure 25 The first pattern of candidate positions for time-domain BV candidates is shown;

[0040] Figure 26 A second pattern of candidate positions for time-domain BV candidates is shown;

[0041] Figure 27 A flowchart of a method for video processing according to embodiments of the present disclosure is shown; and

[0042] Figure 28 A block diagram of a computing device in which various embodiments of the present disclosure may be implemented is shown.

[0043] Throughout all the accompanying figures, the same or similar reference numerals generally refer to the same or similar elements. Detailed Implementation

[0044] The principles of this disclosure will now be described with reference to some embodiments. It should be understood that these embodiments are described for illustrative purposes only and to help those skilled in the art understand and implement this disclosure, and do not imply any limitation on the scope of this disclosure. In addition to the methods described below, the disclosure described herein can be implemented in various other ways.

[0045] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0046] The terms "an embodiment," "embodiment," "example embodiment," etc., used in this disclosure refer to embodiments that may include specific features, structures, or characteristics, but not every embodiment is required to include that specific feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in conjunction with an example embodiment, it is claimed that, whether explicitly described or not, such a feature, structure, or characteristic affecting its relation to other embodiments is within the knowledge of those skilled in the art.

[0047] It should be understood that although the terms “first” and “second”, etc., may be used herein to describe various elements, these elements should not be limited to these terms. These terms are used only to distinguish one element from another. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the exemplary embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0048] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. As used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising,” “including,” “having,” “containing,” and / or “comprising” as used herein indicate the presence of the said features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0049] Example Environment

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

[0051] Video source 112 may include sources such as video capture devices. Examples of video capture devices include, but are not limited to, interfaces for receiving video data from video content providers, computer graphics systems for generating video data, and / or combinations thereof.

[0052] Video data may include one or more images. Video encoder 114 encodes the video data from video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming an encoded representation of the video data. The bitstream may include encoded images and associated data. An encoded image is an encoded representation of an image. Associated data may include sequence parameter sets, image parameter sets, and other syntax structures. I / O interface 116 may include a modulator / demodulator and / or a transmitter. Encoded video data can be directly transmitted to destination device 120 via network 130A through I / O interface 116. Encoded video data may also be stored on storage medium / server 130B for access by destination device 120.

[0053] The destination device 120 may include an I / O interface 126, a video decoder 124, and a display device 122. The I / O interface 126 may include a receiver and / or a modem. The I / O interface 126 may acquire encoded video data from the source device 110 or the storage medium / server 130B. The video decoder 124 may decode the encoded video data. The display device 122 may display the decoded video data to a user. The display device 122 may be integrated with the destination device 120, or it may be external to the destination device 120, which is configured to interface with an external display device.

[0054] The video encoder 114 and the video decoder 124 can operate according to video compression standards such as the High Efficiency Video Codec (HEVC) standard, the Multi-Functional Video Codec (VVC) standard, and other existing and / or future standards.

[0055] Figure 2 This is a block diagram illustrating an example of a video encoder 200 according to some embodiments of the present disclosure. The video encoder 200 may be... Figure 1 An example of a video encoder 114 in system 100 is shown.

[0056] The video encoder 200 can be configured to implement any or all of the technologies disclosed herein. Figure 2 In the example, the video encoder 200 includes multiple functional components. The techniques described in this disclosure can be shared among the various components of the video encoder 200. In some examples, the processor can be configured to perform any or all of the techniques described in this disclosure.

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

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

[0059] Furthermore, although some components (such as motion estimation unit 204 and motion compensation unit 205) can be integrated, for interpretable purposes, these components are... Figure 2 The examples are shown separately.

[0060] The segmentation unit 201 can segment an image into one or more video blocks. The video encoder 200 and the video decoder 300 can support various video block sizes.

[0061] The mode selection unit 203 can, for example, select one of several coding modes (intra-coding or inter-coding) based on the error result, and provide the resulting intra-coded or inter-coded block to the residual generation unit 207 to generate residual block data, and to the reconstruction unit 212 to reconstruct the coded block for use as a reference image. In some examples, the mode selection unit 203 can select an intra-inter-prediction joint prediction (CIIP) mode, in which prediction is based on inter-prediction signals and intra-prediction signals. In the case of inter-prediction, the mode selection unit 203 can also select a resolution for the block based on the motion vector (e.g., sub-pixel precision or integer pixel precision).

[0062] To perform inter-frame prediction on the current video block, motion estimation unit 204 can generate motion information for the current video block by comparing one or more reference frames from buffer 213 with the current video block. Motion compensation unit 205 can determine the predicted video block for the current video block based on the motion information and decoded samples of images from buffer 213 other than the image associated with the current video block.

[0063] Motion estimation unit 204 and motion compensation unit 205 can perform different operations on the current video block, for example, depending on whether the current video block is in an I-strip, P-strip, or B-strip. As used herein, an "I-strip" can refer to a portion of an image composed of macroblocks, all of which are based on macroblocks within the same image. Furthermore, as used herein, in some aspects, "P-strip" and "B-strip" can refer to portions of an image composed of macroblocks independent of macroblocks within the same image.

[0064] In some examples, motion estimation unit 204 can perform unidirectional prediction on the current video block, and can search reference images in list 0 or list 1 to find a reference video block for the current video block. Motion estimation unit 204 can then generate a reference index indicating the reference image containing the reference video block in list 0 or list 1, and a motion vector indicating the spatial displacement between the current video block and the reference video block. Motion estimation unit 204 can output the reference index, prediction direction indicator, and motion vector as motion information for the current video block. Motion compensation unit 205 can generate a predicted video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0065] Alternatively, in other examples, motion estimation unit 204 can perform bidirectional prediction on the current video block. Motion estimation unit 204 can search reference images in list 0 to find a reference video block for the current video block, and can also search reference images in list 1 to find another reference video block for the current video block. Motion estimation unit 204 can then generate multiple reference indices and multiple motion vectors, the multiple reference indices indicating multiple reference images containing multiple reference video blocks in lists 0 and 1, and the multiple motion vectors indicating multiple spatial displacements between the multiple reference video blocks and the current video block. Motion estimation unit 204 can output the multiple reference indices and multiple motion vectors of the current video block as motion information for the current video block. Motion compensation unit 205 can generate a predicted video block for the current video block based on the multiple reference video blocks indicated by the motion information of the current video block.

[0066] In some examples, the motion estimation unit 204 can output a complete set of motion information for use in the decoder's decoding process. Alternatively, in some embodiments, the motion estimation unit 204 can reference the motion information of another video block to transmit the motion information of the current video block via a signal. For example, the motion estimation unit 204 can determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.

[0067] In one example, the motion estimation unit 204 may indicate a value in the syntax structure associated with the current video block that indicates to the video decoder 300 that the current video block has the same motion information as another video block.

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

[0069] As discussed above, the video encoder 200 can transmit motion vectors via signals in a predictive manner. Two examples of predictive signaling techniques that can be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and Merge Pattern Signaling.

[0070] Intra-prediction unit 206 can perform intra-prediction on the current video block. When intra-prediction unit 206 performs intra-prediction on the current video block, it can generate prediction data for the current video block based on decoded samples from other video blocks in the same frame. The prediction data for the current video block can include the predicted video block and various syntax elements.

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

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

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

[0074] After the transform processing unit 208 generates a transform coefficient video block associated with the current video block, the quantization unit 209 can quantize the transform coefficient video block associated with the current video block based on one or more quantization parameter (QP) values ​​associated with the current video block.

[0075] The inverse quantization unit 210 and the inverse transform unit 211 can apply inverse quantization and inverse transform to the transform coefficient video block, respectively, to reconstruct the residual video block from the transform coefficient video block. The reconstruction unit 212 can add the reconstructed residual video block to the corresponding samples of one or more predicted video blocks generated by the prediction unit 202 to produce a reconstructed video block associated with the current video block for storage in the buffer 213.

[0076] After the video block is reconstructed by reconstruction unit 212, a loop filtering operation can be performed to reduce video block artifacts in the video block.

[0077] Entropy encoding unit 214 can receive data from other functional components of video encoder 200. When entropy encoding unit 214 receives data, it can perform one or more entropy encoding operations to generate entropy-encoded data and output a bitstream including the entropy-encoded data.

[0078] Figure 3 This is a block diagram illustrating an example of a video decoder 300 according to some embodiments of the present disclosure. The video decoder 300 may be... Figure 1 An example of video decoder 124 in system 100 is shown.

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

[0080] exist Figure 3 In the example, the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 can perform a decoding process that is generally contrasted with the encoding process described with respect to the video encoder 200.

[0081] Entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded blocks of video data). Entropy decoding unit 301 can decode the entropy-encoded video data, and motion compensation unit 302 can determine motion information from the entropy-decoded video data, including motion vectors, motion vector precision, reference picture list indices, and other motion information. Motion compensation unit 302 can determine such information, for example, by performing AMVP and Merge mode. AMVP is used, which involves deriving several most likely candidates based on data from neighboring PBs and reference pictures. Motion information typically includes horizontal motion vector displacement values ​​and vertical motion vector displacement values, one or two reference picture indices, and, in the case of a prediction region in a B-strip, an identifier of which reference picture list is associated with each index. As used herein, in some aspects, "Merge mode" may refer to deriving motion information from spatially or temporally neighboring blocks.

[0082] The motion compensation unit 302 can generate motion compensation blocks, possibly by performing interpolation based on an interpolation filter. Identifiers for interpolation filters used with sub-pixel precision can be included in the syntax elements.

[0083] The motion compensation unit 302 can use the interpolation filter used by the video encoder 200 during the encoding of a video block to calculate the interpolated values ​​of sub-integer pixels for the reference block. The motion compensation unit 302 can determine the interpolation filter used by the video encoder 200 based on the received syntax information, and the motion compensation unit 302 can use the interpolation filter to generate a prediction block.

[0084] Motion compensation unit 302 may use at least some of the syntax information to determine the size of the blocks used to encode the encoded video sequence (multiple frames) and / or (multiple stripes), segmentation information describing how each macroblock of the image of the encoded video sequence is segmented, a pattern indicating how each segment is encoded, one or more reference frames (and a list of reference frames) for each inter-frame coded block, and other information for decoding the encoded video sequence. As used herein, in some aspects, a “strip” can refer to a data structure that can be decoded independently of other stripes of the same image in terms of entropy encoding / decoding, signal prediction, and residual signal reconstruction. A strip can be an entire image or a region of an image.

[0085] Intra-prediction unit 303 can use, for example, an intra-prediction mode received in the bitstream to form prediction blocks from spatially adjacent blocks. Dequantization unit 304 dequantizes (i.e., dequantizes) the quantized video block coefficients provided in the bitstream and decoded by entropy decoding unit 301. Inverse transform unit 305 applies an inverse transform.

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

[0087] Some exemplary embodiments of this disclosure will be described in detail below. It should be noted that section headings are used in this document for ease of understanding and not to limit the embodiments disclosed in a section to that section. Furthermore, although some embodiments are described with reference to multi-function video codecs or other specific video codecs, the disclosed techniques are also applicable to other video codec techniques. Furthermore, although some embodiments describe video encoding steps in detail, it should be understood that the corresponding decoding steps for decoding will be implemented by the decoder. Additionally, the term video processing includes video encoding or compression, video decoding or decompression, and video transcoding, in which video pixels are represented from one compression format to another or at different compression bitrates.

[0088] 1. Brief Overview

[0089] This disclosure relates to image / video codecs, and more particularly to temporal block vector prediction. It can be applied to existing video codec standards such as HEVC or standard VVC (Video Codec for Multipurpose). It can also be adapted to future video codec standards or video codecs.

[0090] 2. Introduction

[0091] Video codec standards have primarily evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, while ISO / IEC developed MPEG-1 and MPEG-4 visual standards. The two organizations jointly developed H.262 / MPEG-2 video and H.264 / MPEG-4 Advanced Video Codec (AVC), as well as the H.265 / HEVC standard. Because the H.262 standard is based on a hybrid video codec architecture, it utilizes temporal prediction plus transform coding.

[0092] To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. JVET meetings are held quarterly, and at the April 2018 JVET meeting, the new video codec standard was officially named Multifunctional Video Codec (VVC), and the first version of the VVC Test Model (VTM) was released. The VVC working draft and test model VTM are then updated after each meeting. VVC achieved Technical Completeness (FDIS) at the July 2020 meeting.

[0093] In January 2021, JVET established an exploratory experiment (EE) to achieve enhanced compression efficiency beyond VVC capabilities using novel traditional algorithms. Shortly thereafter, ECM was built as a public software foundation for long-term exploratory work toward next-generation video codec standards.

[0094] 2.1 Intra-Block Copying (IBC)

[0095] Intra-Block Copy (IBC) is a tool used in the HEVC extension on SCC. It is well known to significantly improve the encoding and decoding efficiency of screen content material. Since IBC mode is implemented as a block-level encoding and decoding 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 a reference block that has already been reconstructed within the current image. The luma block vector of the CU encoded with IBC is integer precise. The chroma block vector is also rounded to integer precision. When combined with AMVR, IBC mode can switch between 1-pixel motion vector precision and 4-pixel motion vector precision. CUs encoded with IBC are considered a third prediction mode, distinct from intra-prediction mode or inter-prediction mode. IBC mode is suitable for CUs with a width and height of 64 luma samples or less.

[0096] 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 luminance samples. For non-Merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return valid candidates, a local search based on block matching is performed.

[0097] In hash-based searches, hash key matching (32-bit CRC) between the current block and reference blocks is extended to all allowed block sizes. Hash key calculation for each location in the current image is based on 4×4 sub-blocks. For larger current blocks, a hash key match with the reference block's hash key is determined when all hash keys of all 4×4 sub-blocks match the hash key in the corresponding reference location. If multiple reference blocks are found to match the current block's hash key, the block vector cost for each matching reference is calculated, and the block vector cost with the minimum cost is selected. In block matching searches, the search scope is set to cover both the previous CTU and the current CTU. At the CU level, IBC mode is transmitted via signaling using flags, and it can be transmitted via signaling as either IBC AMVP mode or IBC skip / Merge mode:

[0098] –IBC Skip / Merge Mode: The Merge Candidate Index is used to indicate which block vectors from a list of neighboring candidate IBC codecs are used to predict the current block. The Merge list includes the spatial domain, HMVP, and paired candidates.

[0099] –IBC AMVP Mode: Encodes and decodes block vector differences in the same way as motion vector differences. The block vector prediction method uses two candidates as prediction values, one from the left nearest neighbor and one from the upper nearest neighbor (if IBC is encoded and decoded). When either nearest neighbor is unavailable, a default block vector is used as the prediction value. A signal transmission flag indicates the index of the block vector prediction value.

[0100] 2.1.1. Simplification of IBC Vector Prediction

[0101] The BV predictions for the Merge and AMVP modes in IBC will share a common list of predictions that includes the following elements:

[0102] • Two adjacent airspace locations (e.g.) Figure 4 A1 and B1 in the diagram show the spatial proximity locations used in IBC vector prediction.

[0103] • 5 HMVP entries

[0104] • The default value is zero vector.

[0105] For Merge mode, up to the first 6 entries of the list will be used; for AMVP mode, the first 2 entries of the list will be used. The list must also meet the requirements of a shared Merge list region (sharing the same list within SMR).

[0106] 2.1.2. IBC Reference Area

[0107] To reduce memory consumption and decoder complexity, IBC in VVC only allows the reconstruction of predefined regions to include the current CTU region and some regions of the left CTU. Figure 5 The reference area for the IBC mode is shown, where each block represents a 64x64 lumen sample unit. Figure 5 The current CTU processing order and its available reference points in the current CTU and the left CTU are shown.

[0108] Depending on the location of the current codec CU within the current CTU, the following applies:

[0109] – If the current block falls within the top-left 64x64 block of the current CTU, it can refer to reference points in the bottom-right 64x64 block of the left CTU, in addition to the already reconstructed points in the current CTU, using CPR mode. The current block can also refer to reference points in the bottom-left 64x64 block of the left CTU and the top-right 64x64 block of the left CTU, using CPR mode.

[0110] – If the current block falls within the upper right 64x64 block of the current CTU, then in addition to the samples already reconstructed in the current CTU, if the brightness position (0,64) relative to the current CTU has not yet been reconstructed, the current block can also refer to the reference samples in the lower left 64x64 block and the lower right 64x64 block of the left CTU, using CPR mode; otherwise, the current block can also refer to the reference samples in the lower right 64x64 block of the left CTU.

[0111] – If the current block falls within the lower left 64x64 block of the current CTU, then in addition to the samples already reconstructed in the current CTU, if the brightness position (64,0) relative to the current CTU has not yet been reconstructed, the current block can also refer to reference samples in the upper right and lower right 64x64 blocks of the left CTU, using CPR mode. Otherwise, the current block can also refer to reference samples in the lower right 64x64 block of the left CTU, using CPR mode.

[0112] – If the current block falls within the bottom right 64x64 block of the current CTU, it can refer only to samples that have already been reconstructed in the current CTU, using CPR mode.

[0113] This restriction allows the use of local on-chip memory for hardware implementations to achieve IBC mode.

[0114] 2.1.3. IBC Interaction with Other Encoding Tools

[0115] The interaction between IBC mode and other inter-frame coding / decoding tools in VVC (such as Paired Merge Candidate, History-Based Motion Vector Prediction (HMVP), Intra-Inter Joint Prediction Mode (CIIP), Merge Mode with Motion Vector Difference (MMVD), and Geometric Partitioning Mode (GPM)) is as follows:

[0116] IBC can be used with pairwise merge candidates and HMVP. New pairwise IBC merge candidates can be generated by averaging two IBC merge candidates. For HMVP, IBC movements are inserted into the history cache for future reference.

[0117] –IBC cannot be used with the following inter-frame tools: affine motion, CIIP, MMVD, and GPM.

[0118] – When using DUAL_TREE segmentation, IBC is not allowed for chroma codec blocks. Unlike HEVC screen content codec extensions, the current image is no longer included as one of the reference images in reference image list 0 for IBC prediction. The derivation of motion vectors for IBC modes excludes all neighboring blocks in inter-frame modes, and vice versa. The following IBC design aspects apply:

[0119] –IBC shares the same process as regular MV Merge, including the use of pairwise Merge candidates and history-based motion predictions, but does not allow TMVP and zero vectors because they are invalid for IBC mode.

[0120] – Separate HMVP caches (5 candidates per cache) are used for regular MV and IBC.

[0121] – 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 a merge candidate is invalid (out of range or 0), then a merge is not used. This bitstream consistency constraint is represented by a virtual buffer as described below.

[0122] – For deblocking, IBC is processed as an inter-frame mode.

[0123] – If the current block is encoded and decoded using IBC predictive mode, AMVR does not use quarter pixels; instead, AMVR is signaled to indicate only whether the MV is between pixels or 4 integer pixels.

[0124] – The number of IBC Merge candidates can be transmitted separately in the strip header via signaling from the number of regular, sub-block, and geometry Merge candidates.

[0125] The concept of a virtual buffer is used to describe the permissible reference region for IBC prediction modes and valid block vectors. The CTU size is denoted as ctbSize, and the virtual buffer, ibcBuf, has a width of wIbcBuf = 128x128 / ctbSize and a height of hIbcBuf = ctbSize. For example, for a 128x128 CTU size, the ibcBuf size is also 128x128; for a 64x64 CTU size, the ibcBuf size is 256x64; and for a 32x32 CTU size, the ibcBuf size is 512x32.

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

[0127] – The virtual IBC cache ibcBuf is maintained as follows.

[0128] - At the beginning of decoding each CTU line, refresh the entire ibcBuf with an invalid value of -1.

[0129] – When decoding VPDU(xVPDU, yVPDU) relative to the top left corner of the image, set ibcBuf[x][y] = 0, where x = xVPDU%wIbcBuf, ..., xVPDU%wIbcBuf+Wv-1; y = yVPDU%ctbSize, ..., yVPDU%ctbSize+Wv-1.

[0130] – After decoding, the CU contains (x, y) relative to the top-left corner of the image, and sets ibcBuf[x%wIbcBuf][y%ctbSize] = recSample[x][y]

[0131] – For a block covering coordinates (x, y), it is valid if the following is true for the block vector bv = (bv, bv): Otherwise, it is invalid:

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

[0133] 2.1.4. IBC Virtual Cache Test

[0134] The luminance block vector bvL (luminance block vector with 1 / 16 fractional sample accuracy) should comply with the following constraints:

[0135] –CtbSizeY is greater than or equal to ((yCb+(bvL>>4))&(CtbSizeY-1))+cbHeight.

[0136] –IbcVirBuf[(x+(bvL>>4))&(IbcBufWidthY-1)][(y+(bvL>>4))&(CtbSizeY-1)] should not be equal to -1 for x=xCb..xCb+cbWidth-1 and y=yCb..yCb+cbHeight-1.

[0137] Otherwise, bvL is considered invalid bv.

[0138] - Samples are processed in units of CTB. The array size for each luminance CTB, in both width and height, is CtbSizeY in units of samples.

[0139] –(xCb, yCb) represents the brightness position of the top-left sample of the current luminance block relative to the top-left luminance sample of the current image.

[0140] –cbWidth specifies the width of the current codec block in the luminance sample.

[0141] –cbHeight specifies the height of the current codec block in the luminance sample.

[0142] 2.2. IBC Merge / AMVP List Construction

[0143] The IBC Merge / AMVP list is constructed as follows:

[0144] • An IBC Merge / AMVP candidate can only be inserted into the IBC Merge / AMVP candidate list if it is valid.

[0145] • Candidate airspace for the upper right, lower left, and upper left (B0, A0, and B2, etc.) Figure 6 As shown, it illustrates the spatial proximity locations used in the construction of the IBC Merge / AMVP list, and a pairwise average candidate can be added to the IBC Merge / AMVP candidate list.

[0146] • Template-based adaptive reordering (ARMC-TM) is applied to the IBC Merge list.

[0147] The HMVP table size for IBC is increased to 25. After deriving at most 20 IBC Merge candidates using full deduplication, they are reordered together. After reordering, the top 6 candidates with the lowest template matching cost are selected as the final candidates in the IBC Merge list.

[0148] The zero vector candidate used to populate the IBC Merge / AMVP list is 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.

[0149] Three candidates are located at the nearest corner of the reference region, and three additional candidates are determined in the middle of three sub-regions (A, B, and C). The coordinates of the three sub-regions are determined by the width and height of the current block, as well as the ΔX and ΔY parameters. Figure 7 As shown, it illustrates the filling candidates for replacing the zero vector in the IBC list.

[0150] 2.3. IBC with Template Matching

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

[0152] Compared to the list used in the regular IBC Merge mode, the IBC-TM Merge list is modified to select candidates based on a deduplication method, utilizing the motion distance between candidates as in the regular TM Merge mode. The end of zero motion execution is replaced by motion vectors on 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.

[0153] In IBC-TM Merge mode, the selected candidates are refined using a template matching method prior to the RDO or decoding process. IBC-TM Merge mode competes with the regular IBC Merge mode and transmits the TM-Merge flag via signal transmission.

[0154] In the IBC-TM AMVP mode, up to three candidates are selected from the IBC-TM Merge list. Each of the three selected candidates is refined using a template matching method and ranked according to its resulting template matching cost. Typically, only the top two candidates are considered during motion estimation.

[0155] Template matching refinement for both the IBC-TM Merge mode and the AMVP mode is very simple because the IBC motion vector is constrained to (i) integers and (ii) in the form of... Figure 8Within the reference area shown, the IBC reference area is illustrated, depending on the current CU position. Therefore, in IBC-TM Merge mode, all thinning is performed with integer precision, and in IBC-TMAMVP mode, it is performed with integer or 4-pixel precision depending on the AMVR value. This thinning only accesses samples that are not interpolated. In both cases, the motion vectors for thinning and the template used in each thinning step must adhere to the constraints of the reference area.

[0156] 2.4. IBC Reference Area

[0157] The IBC reference area extends to the two CTU rows above. Figure 9 The reference region used for encoding and decoding CTU(m, n) is shown. Specifically, for a CTU(m, n) to be encoded and decoded, 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 slice, strip, or picture. When the CTU size is 256, the reference region is limited to the uppermost CTU row. This setting ensures that for CTU sizes of 128 or 256, IBC does not require additional memory in the current ETM platform. The per-sample block vector search (or local search) range is horizontally limited to [-(C<<1), C>>2] and vertically limited to [-C, C>>2] to accommodate the reference region expansion, where C represents the CTU size.

[0158] 2.5. Reconstructing and Reordering IBC (RR-IBC)

[0159] This allows for Reconstruction-Reordering IBC (RR-IBC) mode for IBC codecs. When RR-IBC is applied, samples in the reconstructed block are flipped according to the flip type of the current block. On the encoder side, the original block is flipped before motion search and residual calculation, while the predicted block is derived without flipping. On the decoder side, the reconstructed block is flipped back to recover the original block.

[0160] For RR-IBC encoded blocks, two flipping methods are supported: horizontal flipping and vertical flipping. First, for IBCAMVP encoded blocks, a syntax flag is signaled indicating whether the reconstruction should be flipped. If flipped, another flag specifying the flipping type is further signaled. For IBC Merge, the flipping type is inherited from neighboring blocks in the absence of syntax signaling. Considering horizontal or vertical symmetry, the current block and reference block are typically horizontally or vertically aligned. Therefore, when a horizontal flip is applied, the vertical component of the BV is not signaled and is presumed to be equal to 0. Similarly, when a vertical flip is applied, the horizontal component of the BV is not signaled and is presumed to be equal to 0.

[0161] Figure 10A An illustration of BV adjustment for horizontal flipping is shown. Figure 10B An illustration is shown for BV adjustment for vertical flipping.

[0162] To better utilize the symmetry property, a flip-aware BV adjustment scheme is applied to refine the block vector candidates. For example, as... Figure 10A and Figure 10B As shown, (xnbr, ynbr) and (xcur, ycur) represent the coordinates of the center sample points of the neighboring block and the current block, respectively, and BVnbr and BVcur represent the BV values ​​of the neighboring block and the current block, respectively. Instead of directly inheriting the BV from the neighboring block, when the neighboring block is encoded and decoded with a horizontal flip, the horizontal component of BVcur is calculated by adding the motion displacement to the horizontal component of BVnbr (denoted as BVnbrh), i.e., BVcurh = 2(xnbr - xcur) + BVnbrh. Similarly, when the neighboring block is encoded and decoded with a vertical flip, the vertical component of BVcur is calculated by adding the motion displacement to the vertical component of BVnbr (denoted as BVnbrv), i.e., BVcurv = 2(ynbr - ycur) + BVnbrv.

[0163] 2.6. IBC Merge Mode with Block Vector Difference (IBC-MBVD)

[0164] Affine MMVD and GPM-MMVD have already been adopted as extensions to the regular MMVD mode. Extending the MMVD mode to the IBCMeerge mode is a natural progression.

[0165] In IBC-MBVD, 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 direction is two horizontal directions and two vertical directions.

[0166] A base candidate is selected from the top five candidates in the reordered IBC Merge list. Then, all possible MBVD refinement positions (20×4) for each base candidate are reordered based on the SAD cost between the template (the row above the current block and the row to the left of the column) and its reference at each refinement position. Finally, the top 8 refinement positions with the lowest template SAD cost remain as available positions and are therefore used for MBVD index encoding and decoding. The MBVD index is binarized by Rice encoding and decoding with a parameter equal to 1.

[0167] Blocks encoded and decoded by IBC-MBVD do not inherit the flip type from neighboring blocks encoded and decoded by RR-IBC.

[0168] 2.7. Intra-frame template matching

[0169] Intra-frame template matching prediction (intra-frame TMP) is a special intra-frame prediction mode that copies the best prediction block from the reconstructed portion of the current frame, with its L-shaped template matching the current template. For a predefined search range, the encoder searches for the template most similar to the current template in the reconstructed portion of the current frame and uses the corresponding block as the prediction block. The encoder then transmits the use of this mode via signal transmission and performs the same prediction operation on the decoder side.

[0170] Figure 11 The intra-frame template matching search region used is shown. This is achieved by matching the L-shaped causal nearest neighbors of the current block with the following... Figure 11 The prediction signal is generated by matching another block in a predefined search region.

[0171] R1: Current CTU

[0172] R2: Top left CTU,

[0173] R3: Above CTU,

[0174] R4: Left CTU.

[0175] The sum of absolute differences (SAD) is used as the cost function.

[0176] Within each region, the decoder searches for the template with the minimum SAD relative to the current one and uses its corresponding block as the prediction block.

[0177] The dimensions of all regions (SearchRange_w, SearchRange_h) are set to be proportional to the block dimensions (BlkW, BlkH) of each pixel having a fixed number of SAD comparisons. That is: SearchRange_w = a*BlkW, SearchRange_h = a * BlkH.

[0178] Here, 'a' is a constant that controls the gain / complexity tradeoff. In practice, 'a' equals 5. Intra-frame template matching is enabled for CUs with both width and height less than or equal to 64. This maximum CU size for intra-frame template matching is configurable.

[0179] When DIMD is not used in the current CU, intra-template matching prediction mode is transmitted at the CU level via a dedicated flag.

[0180] 2.8. Using block vectors derived from IntraTMP for IBC

[0181] A method using block vectors derived from IntraTMP for IBC is proposed. The proposed method stores the IntraTMP block vector in an IBC block vector cache, and the current IBC block can use both the IBC BV and the IntraTMP BV of neighboring blocks as BV candidates for the IBC BV candidate list, such as... Figure 12 As shown, the Figure 12 The use of the IntraTMP block vector for IBC blocks is shown.

[0182] Figure 13A and Figure 13B An example is shown comparing block vector candidates from the IBC block vector candidate list for neighboring blocks that are only IBC encoded and decoded with block vector candidates from the proposed IBC block vector candidate list for neighboring blocks that are both IBC and IntraTMP encoded and decoded. IntraTMP block vectors are added to the IBC block vector candidate list as spatial domain candidates.

[0183] Figure 13A An example of a candidate list of IBC block vectors that only exist is shown. Figure 13B An example of a candidate list of IBC block vectors with both IBC block vectors and IntraTMP block vectors is shown.

[0184] It should be noted that the proposed method makes IBC block vector prediction more efficient by using different block vectors in the absence of additional memory for storing block vectors.

[0185] 2.9. Adaptive Reordering of Merge Candidates with Template Matching (ARMC-TM)

[0186] Merge candidates are adaptively reordered using template matching (TM). The reordering method is applied to the regular Merge pattern, TM Merge pattern, and affine Merge pattern (excluding SbTMVP candidates). For the TM Merge pattern, Merge candidates are reordered before the refinement process.

[0187] First, an initial Merge candidate list is constructed according to a given inspection order, such as spatial, TMVP, non-adjacent, HMVP, paired, and virtual Merge candidates. Then, the candidates in the initial list are divided into several subgroups. For Template Matching (TM) Merge mode and Adaptive DMVR mode, each Merge candidate in the initial list is first refined using TM / multi-pass DMVR. Merge candidates in each subgroup are reordered to generate a reordered Merge candidate list, and the reordering is based on the cost value of template matching. The indices of the selected Merge candidates in the reordered Merge candidate list are signaled to the decoder. For simplicity, Merge candidates in the last, but not the first, subgroup are not reordered. During the Merge motion vector candidate list, all zero candidates from the ARMC reordering process are excluded. For the regular Merge mode and TM Merge mode, the subgroup size is set to 5. For the affine Merge mode, the subgroup size is set to 3.

[0188] Cost Calculation

[0189] During the reordering process, the template matching cost of the merge candidate is measured by the SAD between the samples of the current block's template and their corresponding reference samples. The template includes a set of reconstructed samples adjacent to the current block. The reference samples of the template are located using the motion information of the merge candidate. When the merge candidate utilizes bidirectional prediction, the reference samples of the merge candidate's template are also determined by... Figure 14 The bidirectional prediction generation shown, Figure 14 The template and its reference points in the reference image are shown.

[0190] • Refinement of the initial Merge candidate list

[0191] When multi-pass DMVR is used to derive a refined motion to the initial Merge candidate list, only the first pass of the multi-pass DMVR (i.e., the PU level) is applied during reordering. When template matching is used to derive the refined motion, the template size is set to 1. When the block is flat (where the block width is greater than twice the height) or narrow and elongated (where the height is greater than twice the width), only the top or left template is used during TM motion refinement. TM is expanded to perform 1 / 16 pixel MVD precision. The first four Merge candidates are reordered using the refined motion in TM Merge mode.

[0192] For a sub-block-based merge candidate with a sub-block size equal to Wsub × Hsub, the upper template includes several sub-templates of size Wsub × 1, and the left template includes several sub-templates of size 1 × Hsub. For example... Figure 15 As shown, the Figure 15The template of a block with sub-block motion information using the motion information of the sub-blocks of the current block and the reference sample points of the template are shown. The reference sample points of each sub-template are derived using the motion information of the sub-blocks in the first row and first column of the current block.

[0193] • Reordering criteria

[0194] During the reordering process, if the cost difference between a candidate and its predecessor is less than the lambda value, for example, |D1-D2|<λ, where D1 and D2 are the costs obtained during the first ARMC ordering and λ is the Lagrangian parameter used in the RD criterion on the encoder side, then the candidate is considered redundant.

[0195] The proposed algorithm is defined as follows:

[0196] - Determine the minimum cost difference between a candidate in the list and its predecessor.

[0197] ■ If the minimum cost difference is greater than or equal to λ, the list is considered to be large enough and reordering stops.

[0198] ■ If the minimum cost difference is less than λ, the candidate is considered redundant and moves to another position in the list. This other position is the first position, where there are enough candidates compared to their predecessors.

[0199] - The algorithm stops after a finite number of iterations (if the minimum cost difference is not less than λ).

[0200] This algorithm is applied to regular, TM, BM, and affine Merge modes. Similar algorithms are used in the Merge MMVD prediction method and the symbolic MVD prediction method, which also use ARMC for reordering.

[0201] The value of λ is set to be equal to the rate-distortion criterion λ used to select the best Merge candidate for the low-latency configuration on the encoder side and the value λ corresponding to another QP used for the random access configuration. A set of λ values ​​corresponding to each QP offset transmitted through the signal is provided in the strip header of the QP offset in the SPS or in the QP offset that does not exist in the SPS.

[0202] • Extensions to the AMVP pattern

[0203] The ARMC design also applies to the AMVP pattern, where AMVP candidates are reordered based on TM cost. For template matching for the Advanced Motion Vector Prediction (TM-AMVP) pattern, an initial AMVP candidate list is constructed, which is then refined from the TM to build a more detailed AMVP candidate list. Additionally, MVP candidates with TM costs exceeding a threshold equal to five times the cost of the first MVP candidate are skipped.

[0204] Note that when surround motion compensation is enabled, the MV candidate should take surround offset into account for cropping.

[0205] 2.10. Extended Merge Forecast

[0206] In VVC, the Merge candidate list is constructed by including the following five types of candidates in sequence:

[0207] 1) Airspace MVP from adjacent CUs in airspace,

[0208] 2) Temporal MVP from the same CU,

[0209] 3) Historical MVP from FIFO table

[0210] 4) Paired average MVP

[0211] 5) Zero MV.

[0212] The size of the Merge list is transmitted via signaling in the sequence parameter set header, and the maximum allowed size of the Merge list is 6. For each CU encoding / decoding of the Merge mode, round-down uni-binarization (TU) is used to encode the index of the best Merge candidate. The first binary bit of the Merge index is encoded / decoded using the context, and bypass encoding / decoding is used for the other binary bits.

[0213] The derivation process for the Merge candidates for each category is provided in this session. As done in HEVC, VVC also supports parallel derivation of the Merge candidate list for all CUs within a region of a certain size.

[0214] 2.10.1. Derivation of Airspace Candidates

[0215] The derivation of spatial merge candidates in VVC is the same as that in HEVC, except that the positions of the first two merge candidates are swapped. Figure 16 The four largest Merge candidates are selected from the candidates at the positions depicted. Figure 16 The positions of the spatial merge candidates are shown. The derivation order is B1, A1, B0, A0, and B2. Only position B2 is considered when one or more CUs of positions B0, A0, B1, and A1 are unavailable (e.g., because they belong to another stripe or slice) or during intra-frame encoding / decoding. After adding the candidate for position B1, the addition of the remaining candidates undergoes a redundancy check, which ensures that candidates with the same motion information are excluded from the list, thus improving encoding / decoding efficiency. To reduce computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Figure 17Candidate pairs considered for redundancy checks in the spatial merge candidate are shown. Conversely, only pairs with [other criteria] are considered. Figure 17 The arrow links in the list, and if the corresponding candidate used for redundancy checking does not have the same motion information, the candidate is only added to the list.

[0216] 2.10.2. Time-domain candidate derivation

[0217] In this step, only one candidate is added to the list. Specifically, when deriving the current-domain Merge candidate, the scaled motion vector is derived based on the corresponding CU belonging to the corresponding reference image. The list of reference images and the reference index used to derive the corresponding CU are explicitly transmitted via signaling in the strip header. Figure 18 As shown by the dashed lines, scaled motion vectors for temporal merge candidates are obtained, scaled from the motion vectors of co-located CUs using POC distances tb and td. Here, tb is defined as the POC difference between the current image and its reference image, and td is defined as the POC difference between the co-located reference image and its co-located image. The reference image index for the temporal merge candidate is set to zero.

[0218] Select the position of the time-domain candidate between candidate C0 and candidate C1, such as Figure 19 As shown. If the CU at position C0 is unavailable, intra-frame encoded or decoded, or outside the current line of the CTU, then position C1 is used. Otherwise, position C0 is used to derive the temporal merge candidate.

[0219] 2.10.3. Historical Merge Candidate Derivation

[0220] Following the spatial MVP and TMVP, historical MVP (HMVP) merge candidates are added to the merge list. In this method, motion information of previously encoded / decoded blocks is stored in a table and used as the MVP of the current CU. The table with multiple HMVP candidates is maintained during the encoding / decoding process. The table is reset (cleared) when a new CTU row is encountered. Whenever a non-sub-block inter-frame encoded / decoded CU exists, the associated motion information is added to the last entry of the table as a new HMVP candidate.

[0221] The HMVP table size S is set to 6, indicating that up to 5 history-based MVP (HMVP) candidates can be added to the table. When a new candidate is inserted into the table, a constrained First-In-First-Out (FIFO) rule is used, where a redundancy check is first applied to see if the same HMVP already exists in the table. If found, the same HMVP is removed from the table, all HMVP candidates are moved forward, and the same HMVP is inserted as the last entry in the table.

[0222] HMVP candidates can be used during the Merge candidate list construction process. The latest few HMVP candidates in the table are checked and inserted into the candidate list after the TMVP candidates. Redundancy checks are applied to spatial or temporal Merge candidates on the HMVP candidates.

[0223] To reduce the number of redundant check operations, the following simplification is introduced:

[0224] 1. The last two entries in the table are checked for redundancy and are designated as candidates for the A1 and B1 airspaces, respectively.

[0225] 2. Once the total number of available Merge candidates reaches the maximum allowed Merge candidates minus 1, the process of building the Merge candidate list from HMVP is terminated.

[0226] 2.10.4. Derivation of Pairwise Average Merge Candidates

[0227] Pairwise averaged candidates are generated by averaging predefined candidate pairs in the existing Merge candidate list using the first two Merge candidates. The first Merge candidate is defined as p0Cand, and the second Merge candidate can be defined as p1Cand. Averaged motion vectors are calculated for each reference list based on the availability of motion vectors in p0Cand and p1Cand. If both motion vectors are available in a list, they are averaged even if they point to different reference images, and their reference images are set to one of those in p0Cand; if only one motion vector is available, that motion vector is used directly; if no motion vector is available, the list remains invalid. Furthermore, if the half-pixel interpolation filter indices of p0Cand and p1Cand are different, they are set to 0.

[0228] If the Merge list is not full after adding pairwise average Merge candidates, insert zero MVP at the end until the maximum number of Merge candidates is encountered.

[0229] 2.10.5. Merge Estimation Region

[0230] The Merge Estimation Region (MER) allows for the independent derivation of the Merge candidate list for CUs within the same Merge Estimation Region (MER). The generation of the Merge candidate list for the current CU does not include candidate blocks within the same MER as the current CU. Furthermore, the update process for the candidate list of motion vector predictions based on history is updated only if (xCb+cbWidth)>>Log2ParMrgLevel is greater than xCb>>Log2ParMrgLevel and (yCb+cbHeight)>>Log2ParMrgLevel is greater than (yCb>>Log2ParMrgLevel), where (xCb, yCb) is the top-left brightness sample position of the current CU in the image and (cbWidth, cbHeight) is the CU size. The MER size is selected on the encoder side and is transmitted via signaling as log2_parallel_merge_level_minus2 in the sequence parameter set.

[0231] 2.10.6. Non-adjacent airspace candidates

[0232] In ECM, non-adjacent airspace merge candidates, such as those in JVET-L0399, are inserted after the TMVP in the regular merge candidate list. Figure 20 The diagram shows the patterns of spatial merge candidates. Figure 20 The spatial neighbor blocks used to derive spatial merge candidates are shown. The distance between non-adjacent spatial candidates and the current codec block is based on the width and height of the current codec block. No line buffer constraints are applied.

[0233] 2.10.7. ARMC based on MV candidate types

[0234] Merge candidates for a single candidate type (e.g., TMVP or Non-Adjacent MVP (NA-MVP)) are reordered based on ARMC™ generation value. The reordered candidates are then added to the Merge candidate list. For the TMVP candidate type, more TMVP candidates with more temporal locations and different inter-frame prediction directions are added to perform reordering and selection. Furthermore, the NA-MVP candidate type is further expanded to include more spatially non-adjacent locations. The target reference image for a TMVP candidate can be selected from any reference image in the list based on a scaling factor. The selected reference image is the one whose scaling factor is closest to 1.

[0235] 2.11. Sub-Block-Based Temporal Motion Vector Prediction (SbTMVP) VVC supports the sub-block-based temporal motion vector prediction (SbTMVP) method. Similar to Temporal Motion Vector Prediction (TMVP) in HEVC, SbTMVP uses the motion field in the co-located image to improve motion vector prediction and merge patterns in the current image's CUs. The same co-located images used by TMVP are used for SbTMVP. SbTMVP differs from TMVP in the following two main aspects:

[0236] –TMVP predicts motion at the CU level, but SbTMVP predicts motion at the subCU level;

[0237] – TMVP extracts temporal motion vectors from co-op blocks in the co-op image (the co-op block is the lower right or center block relative to the current CU), while SbTMVP applies motion displacement before extracting temporal motion information from the co-op image, where the motion displacement is obtained from the motion vector of a spatial neighboring block from the spatial neighboring block of the current CU.

[0238] The SbTVMP process in Figure 21A and Figure 21B As shown in the image. Figure 21A The spatial neighbor block used by ATVMP is shown. Figure 21B This demonstrates how to derive the sub-CU motion field by applying motion displacements from spatial neighbors and scaling motion information from corresponding co-located sub-CUs. SbTMVP predicts the motion vectors of sub-CUs within the current CU in two steps. In the first step, it checks... Figure 21A The spatial nearest neighbor A1 in the image is selected. If A1 has a motion vector that uses a co-located image as its reference image, then that motion vector is chosen as the motion displacement to be applied. If this motion is not identified, the motion displacement is set to (0,0).

[0239] In the second step, the motion displacement identified in step 1 is applied (i.e., added to the coordinates of the current block) to obtain sub-CU level motion information (motion vectors and reference indices) from the co-location image, such as... Figure 21B As shown in the image. Figure 21B The example assumes that the motion displacement is set as the motion of block A1. Then, for each sub-CU, the motion information of its corresponding block (the smallest motion grid covering the center sample point) in the co-location image is used to derive the sub-CU's motion information. After identifying the motion information of the co-location sub-CU, it is converted into the current sub-CU's motion vector and reference index in a manner similar to the TMVP process of HEVC, where temporal motion scaling is applied to align the reference image of the temporal motion vector with the reference image of the current CU.

[0240] In VVC, a merge-based sub-block-based Merge list containing SbTVMP candidates and affine Merge candidates is used for signaling in sub-block-based Merge mode. SbTVMP mode is enabled / disabled by the Sequence Parameter Set (SPS) flag. If SbTVMP mode is enabled, the SbTVMP prediction is added as the first entry in the sub-block-based Merge candidate list, followed by the affine Merge candidate. The size of the sub-block-based Merge list is signaled in SPS, and the maximum allowed size of the sub-block-based Merge list in VVC is 5. The sub-CU size used in SbTVMP is fixed at 8x8, and as with affine Merge mode, SbTVMP mode is only applicable to CUs with a width and height greater than or equal to 8.

[0241] The encoding logic for the additional SbTMVP Merge candidate is the same as that for other Merge candidates. That is, for each CU in a P-strip or B-strip, an additional RD check is performed to determine whether to use the SbTMVP candidate.

[0242] 2.12.IBC-CIIP, IBC-GPM and IBC-LIC

[0243] 2.12.1. IBC-CIIP First Option

[0244] Intra-Block Copy Intra-Prediction Joint (IBC-CIIP) is a codec tool for CUs that combines IBC with Merge mode and intra-prediction to obtain two prediction signals, which are then weighted and summed to generate the final prediction. Specifically, if intra-prediction is in planar or DC mode, the final prediction is obtained as follows: P = (w ibc *P ibc +((1< <shift)-w ibc )*P intra +(1<<(shift-1)))>>shift

[0245] Where P ibc and P intra These represent the IBC prediction signal and the intra-frame prediction signal, respectively. If both the upper CU and the left CU are intra-frame encoded and decoded, then (w ibc , shift) is set to equal to (1,2), if one of the top CU and the left CU is intra-coded, then (w ibc , shift) is set to equal to (2,2), if both the top CU and the left CU are encoded and decoded by IBC, then (w ibcThe shift is set to (3,2). Otherwise (i.e., if intra-prediction is in directional mode), the final prediction is obtained by adaptively switching the prediction samples of intra-mode and IBC. For illustrative purposes, assuming the current CU size is w*h and the intra-mode is horizontal or vertical, if both the top neighbor CU and the left neighbor CU are intra-coded, the left 3 / 4 w*h portion (horizontal mode) or the top w*3 / 4 h portion (vertical mode) of the final prediction is set as the intra-prediction signal; and if only one of the top CU and the left CU is intra-coded, the left 1 / 2 w*h portion (horizontal mode) or the top w*1 / 2 h portion (vertical mode) of the final prediction is set as the intra-prediction signal; and if both the top CU and the left CU are IBC or inter-frame codecs, the left 1 / 4 w*h portion (horizontal mode) or the top w*1 / 4 h portion (vertical mode) of the final prediction is set as the intra-prediction signal. In the above content, apart from the intra-frame prediction part, the other parts of the final prediction are set as IBC prediction samples.

[0246] 2.12.2. IBC-CIIP Second Option

[0247] Intra-Block Copy Intra-Prediction Joint (IBC-CIIP) is an encoding / decoding tool for CUs that uses IBC and intra-prediction to obtain two prediction signals, which are then weighted and summed to generate the final prediction as follows: P = (w ibc *P ibc +((1< <shift)-w ibc )*P intra +(1<<(shift-1)))>>shift

[0248] Where P ibc and P intra This represents the IBC prediction signal and the intra-frame prediction signal. For IBC Merge mode and IBCAMVP mode, (w ibc The shift is set to equal (13,4) and (1,1). An intra-prediction mode (IPM) candidate list is used to generate the intra-prediction signal, and the IPM candidate list size is predefined as 2. An IPM index is transmitted via signaling to indicate which IPM is used.

[0249] 2.12.3. IBC with Geometric Segmentation (IBC-GPM)

[0250] Intra-Block Copy with Geometric Partitioning (IBC-GPM) is an encoding / decoding tool that geometrically divides the CU into two sub-partitions. The prediction signals for the two sub-partitions are generated using IBC and intra-prediction. IBC-GPM can be applied to either the regular IBC Merge mode or the IBC-TM Merge mode. The Intra-Prediction Mode (IPM) candidate list is constructed using the same method as GPM with inter-frame and intra-frame prediction for intra-prediction, and the IPM candidate list size is predefined as 3. There are a total of 48 geometric partitioning modes, divided into two sets of geometric partitioning modes as follows:

[0251] Table 1: Geometric segmentation patterns in the first set of geometric segmentation patterns ibc_gpm_partition_idx 0 1 2 3 4 5 6 7 angleIdx 0 0 8 8 16 16 24 24 distanceIdx 1 3 1 3 1 3 1 3

[0252] Table 2: Geometric segmentation patterns in the second set of geometric segmentation patterns ibc_gpm_partition_idx 0 1 2 3 4 5 6 7 8 9 angleIdx 2 2 2 3 3 3 4 4 4 5 distanceIdx 0 1 3 0 1 3 0 1 3 0 ibc_gpm_partition_idx 10 11 12 13 14 15 16 17 18 19 angleIdx 5 5 11 11 11 12 12 12 13 13 distanceIdx 1 3 0 1 3 0 1 3 0 1 ibc_gpm_partition_idx 20 21 22 23 24 25 26 27 28 29 angleIdx 13 14 14 14 18 18 19 19 20 20 distanceIdx 3 0 1 3 1 3 1 3 1 3 ibc_gpm_partition_idx 30 31 32 33 34 35 36 37 38 39 angleIdx 21 21 27 27 28 28 29 29 30 30 distanceIdx 1 3 1 3 1 3 1 3 1 3

[0253] When IBC-GPM is used, the IBC-GPM geometric segmentation mode set flag is transmitted via signaling to indicate whether the first or second geometric segmentation mode set is selected, followed by the geometric segmentation mode index. The IBC-GPM intra-frame flag is transmitted via signaling to indicate whether intra-frame prediction is used for the first sub-segmentation. When intra-frame prediction is used for sub-segmentation, the intra-frame prediction mode index is transmitted via signaling. When IBC is used for sub-segmentation, the merge index is transmitted via signaling.

[0254] 2.12.4. IBC with local illumination compensation (IBC-LIC)

[0255] Intra-Block Copy with Local Illumination Compensation (IBC-LIC) is an encoding / decoding tool that uses linear equations to compensate for local illumination variations within the frame between the IBC-encoded CU and its predicted blocks. Except for using block vectors from the IBC-LIC to generate the reference template, the derivation of the parameters of the linear equations is the same as that for the LIC used for inter-frame prediction. IBC-LIC can be applied to both IBC AMVP and IBC Merge modes. For IBC AMVP mode, an IBC-LIC flag is transmitted via signaling to indicate the use of IBC-LIC. For IBC Merge mode, the IBC-LIC flag is inferred from the Merge candidate.

[0256] 3. Problem

[0257] In current BV prediction (e.g., for both IBC Merge and IBC AMVP modes), time-domain BV prediction is not utilized. To further improve the efficiency of BV prediction, time-domain BV prediction is introduced.

[0258] 4. Detailed Solution

[0259] The detailed embodiments described below should be considered as examples for explaining general concepts. These embodiments should not be interpreted in a narrow sense. Furthermore, these embodiments can be combined in any way.

[0260] The term "block" can refer to a codec tree block (CTB), codec tree unit (CTU), codec block (CB), CU, PU, ​​TU, PB, TB, or a video processing unit comprising multiple samples / pixels. Blocks can be rectangular or non-rectangular.

[0261] W and H are the width and height of the current block (e.g., the luminance block).

[0262] For IBC and intra-frame TMP codecs, the block vector (BV) is used to indicate the displacement from the current block to the reference block, which has been or partially reconstructed within the current frame.

[0263] In the following text, BV candidates are BV predictions or search points. A block has BV information if it is encoded using IBC or intra-frame TMP.

[0264] Time-domain BV prediction

[0265] 1. In one example, time-domain BV prediction can be introduced into BV prediction.

[0266] a. In one example, the BV prediction can be at least one of the following.

[0267] (a) In one example, the BV prediction can be a regular IBC Merge prediction.

[0268] (b) In one example, BV prediction can be a regular IBC AMVP prediction.

[0269] (c) In one example, the BV prediction can be an IBC-TM Merge prediction.

[0270] (d) In one example, BV prediction can be IBC-TM AMVP prediction.

[0271] (e) In one example, BV prediction can be RR-IBC Merge prediction.

[0272] (f) In one example, BV prediction can be RR-IBC AMVP prediction.

[0273] (g) In one example, BV prediction can be IBC-MBVD prediction.

[0274] (h) In one example, BV prediction can be string copy vector prediction.

[0275] (i) In one example, the BV prediction can be any other BV prediction.

[0276] 2. In one example, time-domain BV candidates can be introduced into the BV candidate list.

[0277] a. In one example, the BV candidate list can be at least one of the following.

[0278] (a) In one example, the BV candidate list can be a regular IBC Merge list.

[0279] (b) In one example, the BV candidate list can be a regular IBC AMVP list.

[0280] (c) In one example, the BV candidate list can be the IBC-TM Merge list.

[0281] (d) In one example, the BV candidate list can be the IBC-TM AMVP list.

[0282] (e) In one example, the BV candidate list can be the RR-IBC Merge list.

[0283] (f) In one example, the BV candidate list can be the RR-IBC AMVP list.

[0284] (g) In one example, the BV candidate list can be the IBC-MBVD basic candidate list.

[0285] (h) In one example, the BV candidate list can be any other BV candidate list.

[0286] 3. In one example, a time-domain BV prediction or candidate can be derived in at least one of the following methods.

[0287] a. In one example, if a motion grid (such as a 4x4 grid) covering a time-domain location is available, has BV information, and its BV is valid for the current block, then that time-domain location can be used for time-domain BV candidate derivation.

[0288] b. In one example, if the motion grid (such as a 4x4 grid) covering a time-domain location is unavailable, does not have BV information, or its BV is invalid for the current block, then that time-domain location may not be used for time-domain BV candidate derivation.

[0289] c. In one example, if the motion grid (such as a 4x4 grid) covering a time-domain location is outside the CTU row of the current block, then that time-domain location can be clipped to inside the CTU row of the current block and then used for time-domain BV candidate derivation.

[0290] (a) Alternatively, if the motion grid (such as a 4x4 grid) covering a time-domain location is outside the CTU row of the current block, then that time-domain location may not be used for time-domain BV candidate derivation.

[0291] d. In one example, a location for temporal BV candidates can be selected among several locations in the same image.

[0292] (a) These locations include, for example Figure 22B C0 and C1 in the isotopic images depicted in the figure, Figure 22B The candidate positions for the time-domain candidate are shown.

[0293] (b) C0 can be checked first. If BV cannot be obtained in C0, then C1 is checked.

[0294] (c) C1 can be checked first. If BV cannot be obtained in C1, then C0 is checked.

[0295] (d) If the CU at position C0 is unavailable, does not have BV information, is outside the CTU line of the current block, or its BV is invalid for the current block, then position C1 is used. Otherwise, position C0 is used to derive the temporal BV candidate. This means the priority order is C0->C1.

[0296] (e) Alternative locations can be selected between positions C0 and C1 in the co-located image for temporal BV candidates, such as... Figure 22B As described. If the CU at position C1 is unavailable, does not have BV information, is outside the CTU line of the current block, or its BV is invalid for the current block, then position C0 is used. Otherwise, position C1 is used to derive the temporal BV candidate. This means the priority order is C1->C0.

[0297] e. Alternatively, when deriving temporal BV candidates, candidates corresponding to positions C0 and C1 in the co-located image can be used, such as Figure 22B As depicted in the text.

[0298] (a) For example, the derivation order is C0, C1.

[0299] (a) Alternative sites, derivation order is C1, C0.

[0300] f. In one example, when deriving temporal BV candidates from temporal locations in co-located images, only the BV may be inherited.

[0301] g. In one example, when deriving temporal BV candidates from temporal locations in co-located images, both the BV and IBC-LIC flags can be inherited.

[0302] h. In one example, the width and height of a corresponding block in a corresponding image can be the same as the width and height of the current block in the current image.

[0303] i. In one example, the position of a sibling block in a sibling image can be the same as the position of the current block in the current image.

[0304] j. In one example, the position of a co-op block in the co-op image can be determined by adding a motion displacement to the position of the current block in the current image.

[0305] (a) In one example, the motion displacement can be a spatial nearest neighbor motion vector.

[0306] 1) In one example, spatial neighbors can be Figure 22A The nearest neighbors to the left (A1), top (B1), top right (B0), bottom left (A0), or top left (B2) in the middle. Figure 22A The candidate locations for the airspace candidate are shown.

[0307] 2) In one example, if the spatial neighbor has a motion vector that uses a co-located image as its reference image, then this motion vector can be selected as the motion displacement; if no such motion is identified, the spatial neighbor may not provide a motion displacement or the motion displacement may be set to (0,0).

[0308] 3) In one example, if a spatial neighbor has a motion vector that uses a co-op image as its reference image, then this motion vector can be selected as the motion displacement; if no such motion is identified, a motion vector from reference list 0 or reference list 1 can be scaled to point to the co-op image, and the scaled motion vector can be used as the motion displacement.

[0309] 4) In one example, motion displacements can be derived in a predefined priority order, and the first N (or more) valid motion vectors can be used as (or more) motion displacements.

[0310] i. In one example, N can be 1, 2, 3, 4 or 5.

[0311] ii. In one example, the priority order could be A1->B1->B0->A0->B2.

[0312] iii. In one example, the priority order could be B1->A1->B0->A0->B2.

[0313] iv. In one example, the priority order could be A0->A1->B0->B1->B2.

[0314] (b) In one example, multiple motion displacements with the top M minimum template matching costs can be used to derive temporal BV candidates.

[0315] 1) In one example, M can be 1, 2, 3, 4 or 5.

[0316] k. In one example, when deriving temporal BV candidates, at least one of the following can be used: a candidate selected from position C0 or C1, a candidate selected from position C0Left or C1Left, a candidate selected from position C0Above or C1Above, a candidate selected from position C0AboveRight or C1AboveRight, a candidate selected from position C0BottomLeft or C1BottomLeft, or a candidate selected from position C0AboveLeft or C1AboveLeft, where these positions are in the same image, such as Figure 23 As shown, CXSpatial is the motion displacement derived from the spatial nearest neighbor added to CX (X is 0 or 1, and the spatial domain is left, top, upper right, lower left, or upper left). Figure 23 The candidate positions for time-domain BV candidates are shown, where the spatial domain can be left, top, upper right, lower left, or upper left.

[0317] (a) In one example, up to six time-domain BV candidates can be derived.

[0318] (b) In one example, when deriving temporal BV candidates, candidates selected from positions C0 or C1, or from positions C0Left or C1Left, can be used, as these positions are in the same image, such as Figure 24 As depicted in the example, at most two time-domain BV candidates can be derived. Figure 24 The candidate positions of the time-domain BV candidates are shown.

[0319] (c) In one example, the priority order of C0 and C1 is C0->C1.

[0320] (d) In one example, the priority order of C0 and C1 is C1->C0.

[0321] (e) In one example, the priority order of C0Spatial and C1Spatial can be the same as the priority order of C0 and C1.

[0322] 1) In one example, the space can be left, top, upper right, lower left, or upper left.

[0323] (f) In one example, the priority order of C0Spatial and C1Spatial can be the reverse of the priority order of C0 and C1.

[0324] 1) In one example, the space can be left, top, upper right, lower left, or upper left.

[0325] l. In one example, when deriving temporal BV candidates, at least one of the following can be used: candidates derived from positions C0 and C1, candidates derived from positions C0Left and C1Left, candidates derived from positions C0Above and C1Above, candidates derived from positions C0AboveRight and C1AboveRight, candidates derived from positions C0BottomLeft and C1BottomLeft, and candidates derived from positions C0AboveLeft and C1AboveLeft, where these positions are in the same position in the image, such as Figure 23 As described in the figure, CXSpatial is a motion displacement derived from the spatial nearest neighbor added to CX (X is 0 or 1, and the spatial domain is left, top, upper right, lower left, or upper left).

[0326] (a) In one example, up to 12 time-domain BV candidates can be derived.

[0327] (b) In one example, when deriving temporal BV candidates, candidates derived from positions C0 and C1, and candidates derived from positions C0Left and C1Left, can be used, as these positions are in the same image, such as Figure 24 As depicted in the example, at most four time-domain BV candidates can be derived in this example.

[0328] (c) In one example, the derivation order of C0 and C1 is C0, C1.

[0329] (d) In one example, the derivation order of C0 and C1 is C1, C0.

[0330] (e) In one example, the derivation order of C0Spatial and C1Spatial may be the same as that of C0 and C1.

[0331] 1) In one example, the space can be left, top, upper right, lower left, or upper left.

[0332] (f) In one example, the derivation order of C0Spatial and C1Spatial can be the reverse of the derivation order of C0 and C1.

[0333] 1) In one example, the space can be left, top, upper right, lower left, or upper left.

[0334] m. In one example, the temporal BV candidate can be derived from some specific temporal location.

[0335] (a) In one example, the time-domain location can be predefined.

[0336] (b) In one example, the temporal location can be deduced based on some encoding and decoding information.

[0337] (c) In one example, the temporal location can be derived based on at least one of the current block’s position, width, or height.

[0338] (d) In one example, the distance between the temporal BV candidate and the current codec block can be based on the width and height of the current codec block.

[0339] 1) In one example, the temporal BV candidate mode is in Figure 25 As shown in the image. Figure 25 The first pattern of candidate positions for temporal BV candidates is shown. For each search round, four temporal positions are examined. For each search round i (i>=0), the four temporal positions are {(x+W+i*W),(y+H+i*H)}(RBi), {(x+W / 2+i*W),(y+H / 2+i*H)}(Ctri), {(x+W+i*W),(y+H / 2)}(Ri), and {(x+W / 2),(y+H+i*H)}(Bi).

[0340] i. In one example, if five search rounds are used, the 20 time-domain positions are {(x+W),(y+H)}, {(x+W / 2),(y+H / 2)}, {(x+W),(y+H / 2)}, {(x+W / 2),(y+H)}, {(x+W+W),(y+H+H)}, {(x+W / 2+W),(y+H / 2+H)}, {(x+W+W),(y+H / 2)}, {(x+W / 2),(y+H+H)}, {(x+W+2*W),(y+H+2*H)}, {(x+W / 2+2*W),(y+H / 2+2*H)}. {(x+W+2*W),(y+H / 2)},{(x+W / 2),(y+H+2*H)},{(x+W+3*W),(y+H+3*H)},{(x+W / 2+3*W),(y+H / 2+3*H)},{(x+W+3*W),(y+H / 2)},{ (x+W / 2),(y+H+3*H)}, {(x+W+4*W),(y+H+4*H)}, {(x+W / 2+4*W),(y+H / 2+4*H)}, {(x+W+4*W),(y+H / 2)}, and {(x+W / 2),(y+H+4*H)}.

[0341] i. In one example, for each search round i, a time-domain BV candidate is derived in priority order of RBi->Ctri, and a time-domain BV candidate is derived in priority order of Ri->Bi. At most two time-domain BV candidates can be derived.

[0342] ii. In one example, for each search round i, the derivation order is RBi, Ctri, Ri, Bi, which can derive up to four time-domain BV candidates.

[0343] 2) In one example, the temporal BV candidate mode is in Figure 26 As shown in the image. Figure 26 The second pattern of candidate positions for temporal BV candidates is shown. For each search round, four temporal positions are examined. For each search round i (i>=1), the four temporal positions are {(x+W+i*W),(y+H+i*H)}(RBi), {(x+W / 2+i*W),(y+H / 2+i*H)}(Ctri), {(x+W+i*W),(y+H / 2)}(Ri), and {(x+W / 2),(y+H+i*H)}(Bi). For each search round 0, the four temporal positions are {(x+W),(y+H)}(RB0), {(x+W / 2),(y+H / 2)}(Ctr0), {(x+W),(y+H-4)}(R0), and {(x+W-4),(y+H)}(B0).

[0344] i. In one example, if five search rounds are used, the 20 time-domain positions are {(x+W),(y+H)}, {(x+W / 2),(y+H / 2)}, {(x+W),(y+H-4))}, {(x+W-4),(y+H)}, {(x+W+W),(y+H+H)}, {(x+W / 2+W),(y+H / 2+H)}, {(x+W+W),(y+H / 2)}, {(x+W / 2),(y+H+H)}, {(x+W+2*W),(y+H+2*H)}, {(x+W / 2+2*W),(y+H / 2+2*H)}. {(x+W+2*W),(y+H / 2)},{(x+W / 2),(y+H+2*H)},{(x+W+3*W),(y+H+3*H)},{(x+W / 2+3*W),(y+H / 2+3*H)},{(x+W+3*W),(y+H / 2)},{ (x+W / 2),(y+H+3*H)}, {(x+W+4*W),(y+H+4*H)}, {(x+W / 2+4*W),(y+H / 2+4*H)}, {(x+W+4*W),(y+H / 2)}, and {(x+W / 2),(y+H+4*H)}.

[0345] ii. In one example, for each search round i, a time-domain BV candidate is derived in priority order of RBi->Ctri, and a time-domain BV candidate is derived in priority order of Ri->Bi. At most two time-domain BV candidates can be derived.

[0346] iii. In one example, for each search round i, the derivation order is RBi, Ctri, Ri, Bi, which can derive up to four time-domain BV candidates.

[0347] 3) In one example, any other mode of the time-domain BV candidate can be used.

[0348] n. In one example, all of the above time-domain BV candidates can be combined in any way.

[0349] o. In one example, there may be a constraint on the maximum number (e.g., N) of time-domain BV candidates.

[0350] (a) In one example, the number of time-domain BV candidates may not exceed 5.

[0351] (b) In one example, the number of time-domain BV candidates may not exceed 4.

[0352] (c) Alternatively, there may be a constraint on the maximum number (e.g., M) of temporal BV candidates that can be unique (e.g., after complete deduplication).

[0353] 1) In one example, M can be 5.

[0354] 2) In one example, M can be 4.

[0355] 3) In one example, M can be 3.

[0356] 4) In one example, M can vary depending on the encoding / decoding mode of the current block.

[0357] i. In one example, for IBC-TM AMVP and / or IBC-TM Merge modes, M can be 1 or 2; for other IBC modes, M can be 4 or 5.

[0358] 5) In one example, M can vary depending on the image / strip type.

[0359] i. In one example, if the POC of all reference images of the current strip / image is less than the POC of the current strip / image, then M can be M1; if the POC of at least one reference image of the current strip / image is greater than the POC of the current strip / image, then M can be M2.

[0360] (i) In one example, M1 can be 2; M2 can be 3.

[0361] p. In one example, redundancy checks or deduplication can be performed when deriving time-domain BV candidates.

[0362] (a) In one example, full deduplication can be performed when deriving time-domain BV candidates to ensure that candidates with the same or similar motion information are excluded from the BV candidate list.

[0363] (b) In one example, partial deduplication can be performed when deriving time-domain BV candidates.

[0364] q. In one example, the position of the time-domain BV candidate in the BV candidate list can be one of the following.

[0365] (a) In one example, all time-domain BV candidates can be inserted before the HMVP candidate.

[0366] (b) In one example, a portion of the time-domain BV candidate can be inserted before the HMVP candidate, and the remaining time-domain BV candidate can be inserted after the HMVP candidate.

[0367] (c) In one example, all time-domain BV candidates can be inserted after the HMVP candidate.

[0368] 4. In one example, the number of isotopes used to derive time-domain BV / MV candidates can be N (e.g., N is a positive integer).

[0369] a. In one example, N can be greater than or equal to 1.

[0370] b. In one example, the indication of the corresponding picture for deriving the time-domain BV candidate can be transmitted by signaling at the sequence level / picture group level / picture level / strip level / piece group level, such as in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / strip header / piece group header.

[0371] c. In one example, N reference images with the N smallest POC distances relative to the current image can be selected as co-position images.

[0372] d. In one example, N reference images with the N smallest QP differences relative to the current image can be selected as the corresponding images.

[0373] e. In one example, N reference images with the top N minimum QPs can be selected as co-position images.

[0374] 5. In one example, whether to use time-domain BV prediction (TBVP) and whether to use time-domain MV prediction (TMVP) can use the same indication.

[0375] a. In one example, whether to use time-domain BV prediction (TBVP) and whether to use time-domain MV prediction (TMVP) can be indicated by different criteria.

[0376] b. In one example, whether or not to use temporal BV prediction (TBVP) can be signaled at the sequence level / picture group level / picture level / strip level / piece group level, such as in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / strip header / piece group header.

[0377] BV Candidate Reordering

[0378] 6. In one example, a reordering / refinement process can be performed when deriving the BV candidate list.

[0379] a. In one example, the reordering / refinement process can be based on template matching costs (multiple).

[0380] b. In one example, when constructing the BV candidate list, N1 adjacent spatial candidates and / or N2 temporal candidates and / or N3 HMVP candidates and / or N4 pairwise average candidates and / or N5 predefined BV candidates can be derived partially or entirely using complete deduplication to ensure that there are no duplicate or similar candidates in the list, and then they are reordered together. After reordering, the top N candidates (such as those with the lowest cost) can be selected as the final candidates in the BV candidate list.

[0381] i. In one example, N can be 6 and / or N1 can be 5 and / or N2 can be 10 and / or N3 can be 25 and / or N4 can be 1 and / or N5 can be 6.

[0382] ii. In one example, there may be a constraint on the maximum number (e.g., M) of BV candidates that can be unique (e.g., after full deduplication).

[0383] (i) In one example, M can be 20.

[0384] iii. In one example, adjacent airspace BV candidates can consist of airspace candidates to the left and / or above and / or to the upper right and / or to the lower left and / or to the upper left (example in...). Figure 22A (as shown in the image).

[0385] iv. In one example, the time-domain BV candidate can consist of those specified in list item 3.

[0386] v. In one example, the number of HMVP candidates and / or the size of the HMVP table can be increased to N² (e.g., 25).

[0387] vi. In one example, for paired BV candidates, they can be generated by averaging predefined pairs of existing candidates in the motion candidate list.

[0388] (ii) In one example, predefined pairs can be defined as pairs in a set such as {(0,1),(0,2),(1,2),(0,3),(1,3),(2,3)}, where the numbers represent the motion candidate indices in the motion candidate list.

[0389] vii. In one example, a predefined BV candidate can be located in the IBC reference region.

[0390] c. In one example, ARMC based on BV candidate types can be used to reorder BV candidates with one or more specific candidate types according to one or more criteria.

[0391] i. In one example, when constructing the BV candidate list, M candidates with a specific candidate type (such as having the lowest cost) can be selected from N reordered candidates with that candidate type.

[0392] (i) In one example, M can vary based on the candidate type and / or encoding / decoding mode of the current block.

[0393] (ii) In one example, the candidate type can be a neighboring spatial domain BV candidate. For example, M is 4 and N is 5.

[0394] (iii) In one example, the candidate type can be a time-domain BV candidate. For example, M is 4 and N is 10.

[0395] (iv) In one example, the candidate type can be an HMVP candidate. For example, M is 10 and N is 25.

[0396] (v) In one example, the candidate type can be a pairwise average BV candidate. For example, M is 1 and N is 6.

[0397] (vi) In one example, the candidate type can be a predefined BV candidate. For example, M is 1 and N is 6.

[0398] ii. In one example, multiple BV candidate types (i.e., candidate type combinations) can be reordered together.

[0399] (i) In one example, when constructing the BV candidate list, M candidates with any of the specific BV candidate types (such as having the lowest cost) can be selected from N reordered candidates in the candidate type combination, where M can vary depending on the candidate type combination and / or the encoding mode of the current block.

[0400] (ii) In one example, adjacent spatial candidates and / or temporal candidates and / or HMVP candidates and / or pairwise average candidates and / or predefined BV candidates can be reordered together. For example, M is 6 and N is 20.

[0401] (iii) In one example, at least one BV candidate type of the BV candidate can be reordered using BV candidate type-based ARMC.

[0402] (iv) In one example, N1 HMVP candidates (such as those with the lowest cost) can be selected from the reordered candidates with HMVP candidate types, and the selected N1 HMVP candidates can be reordered together with adjacent spatial candidates and / or temporal candidates and / or pairwise average candidates and / or predefined BV candidates. Finally, M candidates (such as those with the lowest cost) can be selected.

[0403] (v) In one example, N2 temporal candidates (such as those with the lowest cost) can be selected from the reordered candidates with temporal candidate types, and the selected N2 temporal candidates can be reordered together with adjacent spatial candidates and / or HMVP candidates and / or pairwise average candidates and / or predefined BV candidates. Finally, M candidates (such as those with the lowest cost) can be selected.

[0404] (vi) In one example, if a candidate is reordered more than once, its reordering criteria (e.g., template matching cost) can be reused.

[0405] BVP against SbTMVP

[0406] 7. In one example, BVP can be obtained for sub-blocks (such as 4x4 or 8x8) of a block that is encoded or decoded using SbTMVP.

[0407] a. In one example, the BVP can be obtained from the temporal location in the co-located block by SbTMVP.

[0408] General information

[0409] 8. The syntax elements disclosed above can be binarized into flags, fixed-length codes, EG(x) codes, unary codes, rounded unary codes, rounded binary codes, etc. These can be signed or unsigned.

[0410] 9. The syntax elements disclosed above can be encoded and decoded using at least one context model. Alternatively, they can be encoded and decoded using a bypass method.

[0411] 10. The syntax elements (SE) disclosed above can be conditionally transmitted via signals.

[0412] a. The SE is transmitted via signal only when the corresponding function is applicable.

[0413] 11. The syntax elements disclosed above can be transmitted via signaling at the block level / sequence level / picture group level / picture level / strip level / piece group level, such as in the encoding / decoding structure of CTU / CU / TU / PU / CTB / CB / TB / PB or sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / strip header / piece group header.

[0414] 12. In the above examples, a block can refer to a color component / sub-picture / strip / piece / code-decode tree unit (CTU) / CTU row / CTU group / code-decode unit (CU) / prediction unit (PU) / transform unit (TU) / code-decode tree block (CTB) / code-decode block (CB) / prediction block (PB) / transform block (TB) / block / sub-block of a block / sub-region within a block / any other region containing more than one sample point or pixel.

[0415] 13. Whether and / or how the methods disclosed above can be applied to signal transmission at the sequence level / picture group level / picture level / strip level / film group level, such as in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / strip header / film group header.

[0416] 14. Whether and / or how the methods disclosed above can be applied to transmit signals at PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU lines / strips / films / sub-images / other types of areas containing more than one sample point or pixel.

[0417] 15. Whether and / or how the methods disclosed above are applied may depend on the encoded / decoded information, such as block size, color format, single-tree splitting / double-tree splitting, color components, and stripe / picture type.

[0418] Figure 27 A flowchart of a method 2700 for video processing according to an embodiment of the present disclosure is shown. Method 2700 is implemented for the conversion between a current video block and a bitstream of the video. In some embodiments, the conversion may include encoding the current video block into the bitstream. Alternatively or additionally, the conversion may include decoding the current video block from the bitstream.

[0419] At box 2710, the temporal block vector (BV) candidate for the current video block is determined from its temporal location in the co-image of the current video block.

[0420] At box 2720, the transformation is performed based on the temporal BV candidate. At least one of the BV or intra-block copy with local illumination compensation (IBC-LIC) flags is inherited from the temporal location.

[0421] Method 2700 enables the inheritance of BV and / or IBC-LIC flags. In this way, encoding / decoding efficiency and encoding / decoding effectiveness can be improved.

[0422] In some embodiments, BV is inherited, but the IBC-LIC flag is not inherited. That is, only BV can be inherited. Alternatively or additionally, in some embodiments, both BV and the IBC-LIC flag can be inherited.

[0423] In some embodiments, the number of temporal BV candidates for the current video block is less than or equal to a threshold number. For example, multiple temporal BV candidates may be determined for the current video block. The number of multiple temporal BV candidates should be less than or equal to the threshold number.

[0424] In some embodiments, at least one mode of the time-domain BV candidate is used. For example, at least one mode may be Figure 25 The first mode shown or Figure 26 The second mode is shown. Alternatively, any other mode of the time-domain BV candidate can also be used.

[0425] In some embodiments, a time-domain BV candidate may include a first time-domain BV candidate determined in a first manner and a second time-domain BV candidate determined in a second manner. For example, all the time-domain BV candidates mentioned above may be combined in any way.

[0426] In some embodiments, time-domain BV candidates are processed through a complete deduplication process. That is, each time-domain BV candidate can be unique. The total number of these unique time-domain BV candidates is less than or equal to a threshold number.

[0427] In some embodiments, the number of thresholds is based on at least one of the following: image type or strip type.

[0428] In some embodiments, the threshold number is a first value if the image sequence count (POC) of at least one reference image of the current strip or the current image is less than the POC of the current strip or the current image. In some embodiments, at least one POC of at least one reference image includes all POCs of all reference images of the current strip or the current image. That is, if all POCs of all reference images are less than the POC of the current strip or the current image, the threshold can be equal to the first value. For example, the first value can be 2 or any other suitable value.

[0429] Alternatively or additionally, in some embodiments, if at least one POC of at least one reference image of the current strip or the current image is greater than the POC of the current strip or the current image, then the threshold number is a second value. For example, the second value could be 3.

[0430] In some embodiments, the number of thresholds can be 3 or any other suitable number. The number of thresholds can be determined based on any other suitable parameter or rule. The scope of the embodiments disclosed herein is not limited.

[0431] In some embodiments, syntax elements in the bitstream are binarized into at least one of the following: flags, fixed-length codes, exponential Golomb (EG)(x) codes, unary codes, rounded unary codes, or rounded binary codes. In some embodiments, syntax elements are signed or unsigned.

[0432] In some embodiments, syntax elements in the bitstream are encoded or decoded using at least one context model, or are bypassed and encoded / decoded.

[0433] In some embodiments, syntax elements are included in the bitstream based on conditions. For example, a condition could be that the functionality associated with the syntax element is applicable.

[0434] In some embodiments, the syntax element is at at least one of the following: block level, sequence level, picture group level, picture level, strip level, or slice group level.

[0435] In some embodiments, the syntax elements are in the codec structure, which includes at least one of the following: codec tree unit (CTU), codec unit (CU), transform unit (TU), prediction unit (PU), codec tree block (CTB), codec block (CB), transform block (TB), prediction block (PB), sequence header, picture header, sequence parameter set (SPS), video parameter set (VPS), decoding parameter set (DPS), decoding capability information (DCI), picture parameter set (PPS), adaptive parameter set (APS), strip header or slice header.

[0436] In some embodiments, the current video block includes one of the following: color components, sub-pictures, strips, slices, codec tree units (CTUs), CTU rows, CTU groups, codec units (CUs), prediction units (PUs), transform units (TUs), codec tree blocks (CTBs), codec blocks (CBs), prediction blocks (PBs), transform blocks (TBs), blocks, sub-blocks of blocks, sub-regions within blocks, or regions containing more than one sample point or pixel.

[0437] In some embodiments, information about whether and / or how method 2700 is applied is included in the bitstream.

[0438] In some embodiments, information is indicated at one of the following: sequence level, picture group level, picture level, strip level, or slice group level.

[0439] In some embodiments, information is indicated in a sequence header, image header, sequence parameter set (SPS), video parameter set (VPS), decoding parameter set (DPS), decoding capability information (DCI), image parameter set (PPS), adaptive parameter set (APS), strip header, or slice header.

[0440] In some embodiments, the information is indicated in an area containing more than one sample point or pixel.

[0441] In some embodiments, the region includes one of the following: prediction block (PB), transform block (TB), codec block (CB), prediction unit (PU), transform unit (TU), codec unit (CU), virtual pipeline data unit (VPDU), codec tree unit (CTU), CTU row, strip, slice, sub-picture.

[0442] In some embodiments, the information is based on encoded or decoded information.

[0443] In some embodiments, the encoded or decoded information includes at least one of the following: encoding / decoding mode, block size, color format, single-tree segmentation or dual-tree segmentation, color components, stripe type or picture type.

[0444] According to another embodiment of this disclosure, a non-transitory computer-readable recording medium is provided. This non-transitory computer-readable recording medium stores a bitstream of video generated by a method performed by an apparatus for video processing. In this method, a temporal block vector (BV) candidate for a current video block is determined from its temporal position in a co-located image of the current video block. The bitstream is generated based on the temporal BV candidate. At least one of the BV or IBC-LIC flags is inherited from the temporal position.

[0445] According to further embodiments of this disclosure, a method for storing a bitstream of video is provided. In this method, a temporal block vector (BV) candidate for the current video block is determined from its temporal position in a co-located image of the current video block. The bitstream is generated based on the temporal BV candidate. The bitstream is stored in a non-transitory computer-readable recording medium. At least one of the BV or IBC-LIC flags is inherited from the temporal position.

[0446] Embodiments of this disclosure may be described according to the following entries, and their features may be combined in any reasonable manner.

[0447] Item 1. A method for video processing, comprising: for a conversion between a current video block and a bitstream of the video, determining a temporal block vector (BV) candidate for the current video block from a temporal position in a co-located image of the current video block; and performing the conversion based on the temporal BV candidate, wherein at least one of the following flags, either BV or intra-block copy with local illumination compensation (IBC-LIC), is inherited from the temporal position.

[0448] Item 2. The method according to Item 1, wherein the BV is inherited, but the flag of the IBC-LIC is not inherited.

[0449] Item 3. The method described in Item 1, wherein both the BV and the IBC-LIC flags are inherited.

[0450] Item 4. The method according to any one of items 1 to 3, wherein the number of temporal BV candidates for the current video block is less than or equal to the threshold number.

[0451] Item 5. The method according to Item 4, wherein the time-domain BV candidate is processed by a complete deduplication process.

[0452] Item 6. The method according to Item 4 or 5, wherein the number of thresholds is based on at least one of the following: image type, or strip type.

[0453] Item 7. The method according to Item 4 or 5, wherein the threshold number is a first value if the picture order count (POC) of at least one reference picture of the current strip or the current picture is less than the POC of the current strip or the current picture.

[0454] Item 8. The method according to Item 7, wherein the first value is 2.

[0455] Item 9. According to the method described in Item 7, at least one POC of the at least one reference image includes all POCs of all reference images of the current strip or the current image.

[0456] Item 10. The method according to Item 4 or 5, wherein the threshold number is a second value if the image sequence count (POC) of at least one reference image of the current strip or the current image is greater than the POC of the current strip or the current image.

[0457] Item 11. The method according to Item 10, wherein the second value is 3.

[0458] Item 12. The method according to Item 4 or 5, wherein the number of thresholds is 3.

[0459] Item 13. The method according to any one of Items 1 to 12, wherein the syntax elements in the bitstream are binarized into at least one of the following: flags, fixed-length codes, exponential Golomb (EG)(x) codes, unary codes, rounded unary codes, or rounded binary codes.

[0460] Item 14. The method according to Item 13, wherein the syntax element is signed or unsigned.

[0461] Item 15. The method according to any one of Items 1 to 12, wherein the syntax elements in the bitstream are encoded or decoded using at least one context model, or are bypassed and encoded / decoded.

[0462] Item 16. The method according to any one of items 13 to 15, wherein the syntax element is included in the bitstream based on conditions, wherein the conditions include: the functionality associated with the syntax element is applicable.

[0463] Item 17. The method according to any one of items 13 to 16, wherein the syntax element is at at least one of the following: block level, sequence level, picture group level, picture level, strip level, or slice group level.

[0464] Item 18. The method according to any one of items 13 to 17, wherein the syntax element is in a codec structure, the codec structure comprising at least one of the following: a codec tree unit (CTU), a codec unit (CU), a transform unit (TU), a prediction unit (PU), a codec tree block (CTB), a codec block (CB), a transform block (TB), a prediction block (PB), a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a decoding parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptive parameter set (APS), a strip header, or a slice header.

[0465] Item 19. The method according to any one of Items 1 to 18, wherein the current video block comprises one of the following: color components, sub-pictures, strips, slices, codec tree units (CTUs), CTU rows, CTU groups, codec units (CUs), prediction units (PUs), transform units (TUs), codec tree blocks (CTBs), codec blocks (CBs), prediction blocks (PBs), transform blocks (TBs), blocks, sub-blocks of blocks, sub-regions within blocks, or regions containing more than one sample point or pixel.

[0466] Item 20. The method according to any one of items 1 to 19, wherein information about whether and / or how the method is applied is included in the bitstream.

[0467] Item 21. The method according to Item 20, wherein the information is indicated at one of the following: sequence level, picture group level, picture level, strip level, or slice group level.

[0468] Item 22. The method according to Item 20 or Item 21, wherein the information is indicated in a sequence header, picture header, sequence parameter set (SPS), video parameter set (VPS), decoding parameter set (DPS), decoding capability information (DCI), picture parameter set (PPS), adaptive parameter set (APS), strip header or slice header.

[0469] Item 23. The method according to any one of items 20 to 22, wherein the information is indicated in a region containing more than one sample point or pixel.

[0470] Item 24. The method according to Item 23, wherein the region includes one of the following: prediction block (PB), transform block (TB), codec block (CB), prediction unit (PU), transform unit (TU), codec unit (CU), virtual pipeline data unit (VPDU), codec tree unit (CTU), CTU row, strip, slice, sub-picture.

[0471] Item 25. The method according to any one of items 20 to 24, wherein the information is based on encoded or decoded information.

[0472] Item 26. The method according to Item 25, wherein the encoded or decoded information includes at least one of the following: encoding / decoding mode, block size, color format, single-tree segmentation or dual-tree segmentation, color components, stripe type or picture type.

[0473] Item 27. The method according to any one of items 1 to 26, wherein the conversion includes encoding the current video block into the bitstream.

[0474] Item 28. The method according to any one of items 1 to 26, wherein the conversion includes decoding the current video block from the bitstream.

[0475] Item 29. An apparatus for video processing, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method according to any one of Items 1 to 28.

[0476] Item 30. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method according to any one of items 1 to 28.

[0477] Item 31. A non-transitory computer-readable recording medium storing a bitstream of video generated by a method performed by means of an apparatus for video processing, wherein the method comprises: determining a temporal block vector (BV) candidate for the current video block from a temporal position in a co-located picture of the current video block; and generating the bitstream based on the temporal BV candidate, wherein at least one of the BV or a flag of intra-block copy with local illumination compensation (IBC-LIC) is inherited from the temporal position.

[0478] Item 32. A method for storing a bitstream of video, comprising: determining a temporal block vector (BV) candidate for the current video block from a temporal position in a co-located image of the current video block; generating the bitstream based on the temporal BV candidate; and storing the bitstream in a non-transitory computer-readable recording medium, wherein at least one of the following flags, either BV or intra-block copy with local illumination compensation (IBC-LIC), is inherited from the temporal position.

[0479] Example device

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

[0481] It should be understood that, Figure 28 The computing device 2800 shown is for illustrative purposes only and is not intended to imply any limitation on the functionality and scope of the embodiments of this disclosure.

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

[0483] In some embodiments, the computing device 2800 can be implemented as any user terminal or server terminal with computing capabilities. The server terminal can be a server, a large computing device, etc., provided by a service provider. The user terminal can be, for example, any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, stations, units, devices, multimedia computers, multimedia tablet computers, internet nodes, communicators, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices, or any combination thereof. It is conceivable that the computing device 2800 can support any type of interface to the user (such as "wearable" circuitry devices, etc.).

[0484] Processing unit 2810 can be a physical processor or a virtual processor, and can perform various processes based on programs stored in memory 2820. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of computing device 2800. Processing unit 2810 may also be referred to as a central processing unit (CPU), microprocessor, controller, or microcontroller.

[0485] Computing device 2800 typically includes various computer storage media. Such media can be any media accessible by computing device 2800, including but not limited to volatile and non-volatile media, or removable and non-removable media. Memory 2820 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (such as read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), or flash memory) or any combination thereof. Storage cell 2830 can be any removable or non-removable media and may include machine-readable media, such as memory, flash drives, disks, or other media that can be used to store information and / or data and can be accessed within computing device 2800.

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

[0487] Communication unit 2840 communicates with another computing device via a communication medium. Furthermore, the functionality of components in computing device 2800 can be implemented by a single computing cluster or multiple computing machines that can communicate via communication connections. Therefore, computing device 2800 can operate in a networked environment using logical connections to one or more other servers, networked personal computers (PCs), or other general-purpose network nodes.

[0488] Input device 2850 can be one or more of various input devices, such as a mouse, keyboard, trackball, voice input device, etc. Output device 2860 can be one or more of various output devices, such as a monitor, speaker, printer, etc. With the aid of communication unit 2840, computing device 2800 can also communicate with one or more external devices (not shown), such as storage devices and display devices. Computing device 2800 can also communicate with one or more devices that enable a user to interact with computing device 2800, or, if necessary, with any device (e.g., network card, modem, etc.) that enables computing device 2800 to communicate with one or more other computing devices. This communication can be performed via an input / output (I / O) interface (not shown).

[0489] In some embodiments, some or all of the components of computing device 2800 may be arranged in a cloud computing architecture, rather than integrated into a single device. In a cloud computing architecture, components may be remotely provided and work together to achieve the functionality described herein. In some embodiments, cloud computing provides computing, software, data access, and storage services without requiring end users to know the physical location or configuration of the systems or hardware providing these services. In various embodiments, cloud computing provides services via a wide area network (WAN), such as the Internet, using suitable protocols. For example, a cloud computing provider provides applications via a WAN that can be accessed through a web browser or any other computing component. The software or components of the cloud computing architecture, along with the corresponding data, may be stored on servers at remote locations. Computing resources in a cloud computing environment may be consolidated or distributed across remote data center locations. Cloud computing infrastructure may provide services through shared data centers, although they appear as a single access point to users. Therefore, a cloud computing architecture can be used to provide the components and functionality described herein from service providers at remote locations. Alternatively, the components and functionality described herein may be provided by conventional servers or installed directly or otherwise on client devices.

[0490] In embodiments of this disclosure, computing device 2800 may be used to implement video encoding / decoding. Memory 2820 may include one or more video codec modules 2825 having one or more program instructions. These modules are accessible and executable by processing unit 2810 to perform the functions of the various embodiments described herein.

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

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

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

Claims

1. A method for video processing, comprising: For the conversion between the current video block and the bitstream of the video, the temporal block vector (BV) candidate of the current video block is determined from the temporal position in the co-located image of the current video block; as well as Based on the time-domain BV candidates, perform the transformation. At least one of the flags of BV or Intra-Block Copy with Local Illumination Compensation (IBC-LIC) is inherited from the temporal location.

2. The method of claim 1, wherein the BV is inherited, but the IBC-LIC flag is not inherited.

3. The method of claim 1, wherein both the BV and the IBC-LIC flags are inherited.

4. The method according to any one of claims 1 to 3, wherein the number of temporal BV candidates for the current video block is less than or equal to the threshold number.

5. The method of claim 4, wherein the time-domain BV candidate is processed by a complete deduplication process.

6. The method of claim 4 or 5, wherein the number of thresholds is based on at least one of the following: image type, or strip type.

7. The method according to claim 4 or 5, wherein if the image sequence count (POC) of at least one reference image of the current strip or the current image is less than the POC of the current strip or the current image, then the threshold number is a first value.

8. The method of claim 7, wherein the first value is 2.

9. The method of claim 7, wherein at least one POC of the at least one reference image includes all POCs of all reference images of the current strip or the current image.

10. The method according to claim 4 or 5, wherein the threshold number is a second value if the image sequence count (POC) of at least one reference image of the current strip or the current image is greater than the POC of the current strip or the current image.

11. The method of claim 10, wherein the second value is 3.

12. The method according to claim 4 or 5, wherein the number of thresholds is 3.

13. The method according to any one of claims 1 to 12, wherein the syntax elements in the bitstream are binarized into at least one of the following: flags, fixed-length codes, exponential Golomb (EG)(x) codes, unary codes, rounded unary codes, or rounded binary codes.

14. The method of claim 13, wherein the syntax element is signed or unsigned.

15. The method according to any one of claims 1 to 12, wherein the syntax elements in the bitstream are encoded or decoded using at least one context model, or are bypassed and encoded / decoded.

16. The method according to any one of claims 13 to 15, wherein the syntax element is included in the bitstream based on conditions, wherein the conditions include: The functions associated with the grammatical elements are applicable.

17. The method according to any one of claims 13 to 16, wherein the syntax element is at least one of the following: block level, sequence level, picture group level, picture level, strip level, or slice group level.

18. The method according to any one of claims 13 to 17, wherein the syntax element is in a codec structure, the codec structure comprising at least one of the following: a codec tree unit (CTU), a codec unit (CU), a transform unit (TU), a prediction unit (PU), a codec tree block (CTB), a codec block (CB), a transform block (TB), a prediction block (PB), a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a decoding parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptive parameter set (APS), a strip header, or a slice header.

19. The method according to any one of claims 1 to 18, wherein the current video block comprises one of the following: color components, sub-pictures, stripes, slices, codec tree units (CTUs), CTU rows, CTU groups, codec units (CUs), prediction units (PUs), transform units (TUs), codec tree blocks (CTBs), codec blocks (CBs), prediction blocks (PBs), transform blocks (TBs), blocks, sub-blocks of blocks, sub-regions within blocks, or regions containing more than one sample point or pixel.

20. The method according to any one of claims 1 to 19, wherein information about whether and / or how the method is applied is included in the bitstream.

21. The method of claim 20, wherein the information is indicated at one of the following levels: sequence level, picture group level, picture level, strip level, or slice group level.

22. The method of claim 20 or claim 21, wherein the information is indicated in a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a decoding parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptive parameter set (APS), a strip header, or a slice header.

23. The method according to any one of claims 20 to 22, wherein the information is indicated in a region containing more than one sample point or pixel.

24. The method of claim 23, wherein the region comprises one of the following: prediction block (PB), transform block (TB), codec block (CB), prediction unit (PU), transform unit (TU), codec unit (CU), virtual pipeline data unit (VPDU), codec tree unit (CTU), CTU row, strip, slice, sub-picture.

25. The method according to any one of claims 20 to 24, wherein the information is based on encoded or decoded information.

26. The method of claim 25, wherein the encoded / decoded information includes at least one of the following: encoding / decoding mode, block size, color format, single-tree segmentation or dual-tree segmentation, color components, stripe type or picture type.

27. The method of any one of claims 1 to 26, wherein the conversion comprises encoding the current video block into the bitstream.

28. The method of any one of claims 1 to 26, wherein the conversion comprises decoding the current video block from the bitstream.

29. An apparatus for video processing, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 28.

30. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method according to any one of claims 1 to 28.

31. A non-transitory computer-readable recording medium storing a bitstream of video generated by a method performed by means of a video processing apparatus, wherein the method includes: Determine the temporal block vector (BV) candidate of the current video block from its temporal position in the co-located image of the current video block; as well as The bitstream is generated based on the time-domain BV candidates. At least one of the flags of BV or Intra-Block Copy with Local Illumination Compensation (IBC-LIC) is inherited from the temporal location.

32. A method for storing a bitstream of video, comprising: Determine the temporal block vector (BV) candidate of the current video block from its temporal position in the co-located image of the current video block; The bitstream is generated based on the time-domain BV candidates; as well as The bitstream is stored in a non-transitory computer-readable recording medium. At least one of the flags of BV or Intra-Block Copy with Local Illumination Compensation (IBC-LIC) is inherited from the temporal location.

Images