Method and device for video processing and medium

Abstract

The embodiment of the invention provides a video processing scheme. A method for video processing is proposed. The method includes, for a conversion between a current block of a video and a bitstream of the video, determining motion information of the current block based on a merge mode (IBC-MBVD) mode in which motion information of a neighboring block of the current block and intra block copy have a block vector difference, the neighboring block being coded and decoded using a reconstruction reordered intra block copy (RRIBC) mode; and performing conversion based on the motion information of the current block.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to video processing techniques, and more particularly, to the interaction of reconstruction reordered intra block copy (RRIBC) with other IBC-based modes. Background Art

[0002] Nowadays, digital video capabilities are being applied to all aspects of people's lives. For video encoding / decoding, various types of video compression technologies have been proposed, such as MPEG-2, MPEG-4, ITU-T H.263, ITU-TH.264 / MPEG-4 Part 10 Advanced Video Codec (AVC), ITU-T H.265 High Efficiency Video Codec (HEVC) standard, and Versatile Video Codec (VVC) standard. However, it is generally expected that the encoding and decoding quality and encoding and decoding efficiency of video encoding and decoding technologies can be further improved. Summary of the invention

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

[0004] In a first aspect, a method for video processing is provided. The method includes: for conversion between a current block of a video and a bitstream of the video, based on motion information of neighboring blocks of the current block and an intra-frame block copy merge mode with block vector difference (IBC-MBVD) mode, determining motion information of the current block, the neighboring blocks are encoded and decoded using a reconstruction reordered intra-frame block copy (RRIBC) mode; and performing conversion based on the motion information of the current block.

[0005] According to the method of the first aspect of the present disclosure, based on the motion information of the neighboring blocks of the RRIBC codec and the IBC-MBVD mode, the motion information of the current block is determined. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-MBVD mode, thereby advantageously improving the coding efficiency and coding quality.

[0006] In a second aspect, another method for video processing is proposed. The method includes: for conversion between a current block of a video and a bitstream of the video, based on motion information of neighboring blocks of the current block and an intra-block copy template matching merge (IBC-TM-MERGE) mode, determining motion information of the current block, the current block and the neighboring blocks are encoded and decoded using a reconstruction reordered intra-block copy (RRIBC) mode; and performing conversion based on the motion information of the current block.

[0007] According to the method of the second aspect of the present disclosure, based on the motion information of the neighboring blocks of the RRIBC codec and the IBC-TM-MERGE mode, the motion information of the current block of the RRIBC codec is determined. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-TM-MERGE mode, thereby advantageously improving the coding efficiency and coding quality.

[0008] In a third aspect, another method for video processing is proposed. The method includes: for conversion between a current block of a video and a bitstream of the video, based on motion information of neighboring blocks of the current block and an intra-block copy advanced motion vector prediction (IBC-AMVP) mode, determining a motion candidate for the current block, the neighboring blocks being encoded and decoded using a reconstruction reordered intra-block copy (RRIBC) mode; determining motion information of the current block based on the motion candidate; and performing conversion based on the motion information of the current block.

[0009] According to the method of the third aspect of the present disclosure, based on the motion information of the neighboring blocks of the RRIBC codec and the IBC-AMVP mode, the motion information of the current block is determined. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-AMVP mode, thereby advantageously improving the coding efficiency and coding quality.

[0010] In a fourth aspect, a device for video processing is provided. The device includes a processor and a non-volatile memory having instructions thereon. The instructions, when executed by the processor, cause the processor to perform the method according to the first aspect of the present disclosure.

[0011] In a fifth aspect, a non-transitory computer-readable storage medium is provided, wherein the non-transitory computer-readable storage medium stores instructions for causing a processor to execute the method according to the first aspect of the present disclosure.

[0012] In a sixth aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by an apparatus for video processing. The method includes: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-MBVD mode, the neighboring blocks being encoded and decoded using an RRIBC mode; and generating a bitstream based on the motion information of the current block.

[0013] In a seventh aspect, a method for storing a bitstream of a video is proposed. The method includes: determining the motion information of the current block based on the motion information of the neighboring blocks of the current block of the video and the IBC-MBVD mode, and the neighboring blocks are encoded and decoded using the RRIBC mode; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium.

[0014] In an eighth aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a device for video processing. The method includes: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-TM-MERGE mode, the current block and the neighboring blocks being encoded and decoded using an RRIBC mode; and generating a bitstream based on the motion information of the current block.

[0015] In a ninth aspect, a method for storing a bitstream of a video is proposed. The method includes: determining the motion information of the current block based on the motion information of the neighboring blocks of the current block of the video and the IBC-TM-MERGE mode, the current block and the neighboring blocks are encoded and decoded using the RRIBC mode; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium.

[0016] In a tenth aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a device for video processing. The method includes: determining a motion candidate for a current block based on motion information of neighboring blocks of a current block of the video and an IBC-AMVP mode, wherein the neighboring blocks are encoded and decoded using an RRIBC mode; determining motion information of the current block based on the motion candidate; and generating a bitstream based on the motion information of the current block.

[0017] In an eleventh aspect, a method for storing a bitstream of a video is proposed. The method includes: determining a motion candidate of a current block based on motion information of neighboring blocks of a current block of the video and an IBC-AMVP mode, wherein the neighboring blocks are encoded and decoded using an RRIBC mode; determining motion information of the current block based on the motion candidate; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium.

[0018] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the disclosure, nor is it intended to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and other objects, features and advantages of the exemplary embodiments of the present disclosure will become more apparent through 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.

[0020] Figure 1 A block diagram showing an example video encoding and decoding system according to some embodiments of the present disclosure is shown;

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

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

[0023] Figure 4 The current codec tree unit (CTU) processing order and its available reference samples in the current and left CTUs are shown;

[0024] Figure 5 The residual encoding and decoding pass for transforming a skipped block is shown;

[0025] Figure 6 An example of a block encoded and decoded in palette mode is shown;

[0026] Figure 7 A sub-block based index map scan for a palette is shown;

[0027] Figure 8 A decoding flow chart with adaptive color transform (ACT) is shown;

[0028] Fig. 9 The intra-frame template matching search area used is shown;

[0029] Fig.10 An intra block copy (IBC) reference area depending on the current codec unit (CU) position is shown;

[0030] Fig.11A An example of block vector (BV) adjustment for horizontal flipping is shown;

[0031] Fig. 11B An example of BV adjustment for vertical flipping is shown;

[0032] Fig.12 A flowchart of a method for video processing according to an embodiment of the present disclosure is shown;

[0033] Fig.13 A flowchart of another method for video processing according to an embodiment of the present disclosure is shown;

[0034] Fig.14 A flowchart of another method for video processing according to an embodiment of the present disclosure is shown;

[0035] Fig.15 A block diagram of a computing device is shown in which various embodiments of the present disclosure may be implemented.

[0036] Throughout the drawings, same or similar reference numbers generally refer to same or similar elements. DETAILED DESCRIPTION

[0037] The principle of the present disclosure will now be described with reference to some embodiments. It should be understood that these embodiments are described only for the purpose of illustrating and helping those skilled in the art to understand and implement the present disclosure, without implying any limitation on the scope of the present disclosure. In addition to the methods described below, the disclosure described herein can also be implemented in various ways.

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

[0039] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include the particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an example embodiment, whether or not explicitly described, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in relation to other embodiments.

[0040] It should be understood that although the terms "first" and "second" etc. can be used to describe various elements, these elements should not be limited to these terms. These terms are only used to distinguish one element from another element. For example, a first element can be referred to as a second element, and similarly, a second element can 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.

[0041] The terms used herein are only used for the purpose of describing specific embodiments and are 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 "comprises", "includes", and / or "having" when used herein indicate the presence of the features, elements, and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof. Example Environment

[0042] Figure 11 is a block diagram illustrating an example video codec system 100 that can utilize the techniques of the present disclosure. As shown, the video codec 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.

[0043] Video source 112 may include a source such as a video capture device. Examples of a video capture device include, but are not limited to, an interface that receives video data from a video content provider, a computer graphics system for generating video data, and / or combinations thereof.

[0044] The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bitstream. The bitstream may include a bit sequence that forms a codec representation of the video data. The bitstream may include a codec picture and associated data. The codec picture is a codec representation of the picture. The associated data may include a sequence parameter set, a picture parameter set, and other grammatical structures. The I / O interface 116 may include a modulator / demodulator and / or a transmitter. The encoded video data may be directly transmitted to the destination device 120 via the network 130A via the I / O interface 116. The encoded video data may also be stored on a storage medium / server 130B for access by the destination device 120.

[0045] 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 obtain 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 the user. The display device 122 may be integrated with the destination device 120, or may be outside the destination device 120, which is configured to be connected to an external display device interface.

[0046] The video encoder 114 and the video decoder 124 may operate according to a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVC) standard, and other existing and / or further standards.

[0047] Figure 2is a block diagram showing an example of a video encoder 200 according to some embodiments of the present disclosure, which may be Figure 1 An example of a video encoder 114 in the system 100 is shown.

[0048] Video encoder 200 may be configured to implement any or all of the techniques of this disclosure. Figure 2 In the example of , video encoder 200 includes multiple functional components. The techniques described in this disclosure can be shared between the various components of video encoder 200. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

[0049] In some embodiments, the video encoder 200 may include a partitioning unit 201, a prediction unit 202, a residual generation unit 207, a transformation unit 208, a quantization unit 209, an inverse quantization unit 210, an inverse transformation unit 211, a reconstruction unit 212, a buffer 213 and an entropy coding and decoding unit 214, and 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.

[0050] 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 may perform prediction in an IBC mode, where at least one reference picture is a picture where the current video block is located.

[0051] Furthermore, although some components (such as the motion estimation unit 204 and the motion compensation unit 205) may be integrated, for the purpose of explanation, these components are described in detail below. Figure 2 are shown separately in the example.

[0052] The partitioning unit 201 may partition a picture into one or more video blocks. The video encoder 200 and the video decoder 300 may support various video block sizes.

[0053] The mode selection unit 203 may select one of a plurality of codec modes (intra-frame coding or inter-frame coding), for example, based on the error result, and provide the generated intra-frame codec block or inter-frame codec block to the residual generation unit 207 to generate residual block data, and to the reconstruction unit 212 to reconstruct the codec block for use as a reference picture. In some examples, the mode selection unit 203 may select a combination of intra-frame and inter-frame prediction (CIIP) modes, where the prediction is based on an inter-frame prediction signal and an intra-frame prediction signal. In the case of inter-frame prediction, the mode selection unit 203 may also select a resolution for the motion vector (e.g., sub-pixel precision or integer pixel precision) for the block.

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

[0055] The motion estimation unit 204 and the motion compensation unit 205 may perform different operations on the current video block, for example, depending on whether the current video block is in an I slice, a P slice, or a B slice. As used herein, an "I slice" may refer to a portion of a picture consisting of macroblocks, all of which are based on macroblocks within the same picture. Furthermore, as used herein, in some aspects, a "P slice" and a "B slice" may refer to a portion of a picture consisting of macroblocks that are independent of macroblocks in the same picture.

[0056] In some examples, the motion estimation unit 204 may perform unidirectional prediction on the current video block, and the motion estimation unit 204 may search the reference pictures of list 0 or list 1 to find the reference video block for the current video block. The motion estimation unit 204 may then generate a reference index and a motion vector, the reference index indicating the reference picture in list 0 or list 1 containing the reference video block, and the motion vector indicating the spatial displacement between the current video block and the reference video block. The motion estimation unit 204 may output the reference index, the prediction direction indicator, and the motion vector as the motion information of the current video block. The motion compensation unit 205 may 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.

[0057] Alternatively, in other examples, the motion estimation unit 204 may perform bidirectional prediction on the current video block. The motion estimation unit 204 may search the reference pictures in list 0 for a reference video block for the current video block, and may also search the reference pictures in list 1 for another reference video block for the current video block. The motion estimation unit 204 may then generate a plurality of reference indexes and a plurality of motion vectors, the plurality of reference indexes indicating a plurality of reference pictures in list 0 and list 1 containing a plurality of reference video blocks, and the plurality of motion vectors indicating a plurality of spatial displacements between the plurality of reference video blocks and the current video block. The motion estimation unit 204 may output the plurality of reference indexes and the plurality of motion vectors of the current video block as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block for the current video block based on the plurality of reference video blocks indicated by the motion information of the current video block.

[0058] In some examples, motion estimation unit 204 may output a complete set of motion information for use in a decoding process by a decoder. Alternatively, in some embodiments, motion estimation unit 204 may signal motion information of a current video block with reference to motion information of another video block. For example, motion estimation unit 204 may determine that motion information of a current video block is sufficiently similar to motion information of a neighboring video block.

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

[0060] In another example, the motion estimation unit 204 may identify another video block and a motion vector difference (MVD) in a 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. The video decoder 300 may use the motion vector of the indicated video block and the motion vector difference to determine the motion vector of the current video block.

[0061] As discussed above, the video encoder 200 may signal motion vectors in a predictive manner.Two examples of prediction signaling techniques that may be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and merge mode signaling.

[0062] The intra prediction unit 206 may perform intra prediction on the current video block. When the intra prediction unit 206 performs intra prediction on the current video block, the intra prediction unit 206 may generate prediction data for the current video block based on decoded samples of other video blocks in the same picture. The prediction data for the current video block may include a prediction video block and various syntax elements.

[0063] The residual generation unit 207 may generate residual data for the current video block by subtracting (e.g., indicated by a minus sign) the prediction video block(s) of the current video block from the current video block. The residual data of the current video block may include residual video blocks corresponding to different sample portions of samples in the current video block.

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

[0065] Transform processing unit 208 may generate one or more transform coefficient video blocks for a current video block by applying one or more transforms to the residual video block associated with the current video block.

[0066] After transform processing unit 208 generates a transform coefficient video block associated with the current video block, quantization unit 209 may 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.

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

[0068] After reconstruction unit 212 reconstructs the video block, a loop filtering operation may be performed to reduce video blocking artifacts in the video block.

[0069] The entropy coding unit 214 may receive data from other functional components of the video encoder 200. When the entropy coding unit 214 receives data, the entropy coding unit 214 may perform one or more entropy coding operations to generate entropy coded data and output a bitstream including the entropy coded data.

[0070] Figure 3 is a block diagram showing an example of a video decoder 300 according to some embodiments of the present disclosure, which may be Figure 1 An example of a video decoder 124 in the system 100 is shown.

[0071] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. Figure 3 In the example of , video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared between the various components of video decoder 300. In some examples, a processor can be configured to perform any or all of the techniques described in this disclosure.

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

[0073] The entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy encoded video data (e.g., encoded video data blocks). The entropy decoding unit 301 can decode the entropy encoded video data, and the motion compensation unit 302 can determine motion information from the entropy decoded video data, the motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 302 can determine the information, for example, by performing AMVP and merge mode. AMVP is used, including deriving several most likely candidates based on data and reference pictures of adjacent PBs. The motion information typically includes horizontal and vertical motion vector displacement values, one or two reference picture indexes, and in the case of prediction areas in B strips, also includes an identification 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 blocks that are adjacent in space or time.

[0074] The motion compensation unit 302 may generate motion compensated blocks, possibly performing interpolation based on interpolation filters.Identifiers for the interpolation filters used with sub-pixel precision may be included in the syntax elements.

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

[0076] The motion compensation unit 302 may use at least part of the syntax information to determine the size of blocks used to encode (multiple) frames and / or (multiple) slices of the encoded video sequence, partition information describing how each macroblock of a picture of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-frame coding block, and other information for decoding the encoded video sequence. As used herein, in some aspects, a "slice" may refer to a data structure that can be decoded independently of other slices of the same picture in terms of entropy coding, signal prediction, and residual signal reconstruction. A slice may be an entire picture, or it may be a region of a picture.

[0077] The intra prediction unit 303 may use, for example, an intra prediction mode received in the bitstream to form a prediction block from spatially neighboring blocks. The inverse quantization unit 304 inverse quantizes (i.e., dequantizes) the quantized video block coefficients provided in the bitstream and decoded by the entropy decoding unit 301. The inverse transform unit 305 applies an inverse transform.

[0078] The reconstruction unit 306 may 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 prediction unit 303. If necessary, a deblocking filter may also be applied to filter the decoded block to remove blocking artifacts. The decoded video block is then stored in a buffer 307, which provides reference blocks for subsequent motion compensation / intra prediction, and the buffer 307 also generates the decoded video for presentation on a display device.

[0079] Some example embodiments of the present disclosure will be described in detail below. It should be noted that the section titles used in this document are for ease of understanding, and the embodiments disclosed in the section are not limited to that section. In addition, although some embodiments are described with reference to general video codecs or other specific video codecs, the disclosed technology is also applicable to other video coding and decoding technologies. In addition, although some embodiments describe the video encoding steps in detail, it should be understood that the corresponding decoding steps of canceling the encoding will be implemented by the decoder. In addition, the term "video processing" includes video coding or compression, video decoding or decompression, and video transcoding, in which video pixels are represented from one compression format to another compression format or at different compression bit rates. 1 Brief Overview The present disclosure relates to video coding technology. Specifically, it is about the interaction of RRIBC and other coding tools in image / video coding. It can be applied to existing video coding standards such as HEVC, VVC, etc. It can also be applied to future video decoding standards or video codecs. 2 Introduction Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, ISO / IEC developed MPEG-1 and MPEG-4 Visual, and the two organizations jointly developed H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Codec (AVC) and H.265 / HEVC standards. Since H.262, video codec standards have been based on a hybrid video codec structure, in which temporal prediction plus transform codec is used. In order to explore future video codec technologies beyond HEVC, VCEG and MPEG jointly founded the Joint Video Exploration Team (JVET) in 2015. JVET meetings are held simultaneously every quarter, and the new video codec standard was officially named Versatile Video Codec (VVC) at the JVET meeting in April 2018, when the first version of the VVC Test Model (VTM) was released. The VVC working draft and the test model VTM are updated after each meeting. The VVC project achieved technical completion (FDIS) at the July 2020 meeting. In January 2021, JVET established an Exploration Experiment (EE) to leverage novel traditional algorithms to enhance compression efficiency beyond VVC capabilities. Soon, ECM was built as a common software foundation for long-term exploratory work toward the next generation of video codec standards. 2.1 Existing screen content encoding and decoding tools 2.1.1 Intra-block copy (IBC) Intra-block copying (IBC) is a tool adopted in the HEVC extension on SCC. It is well known that it significantly improves the encoding and decoding efficiency of screen content materials. Since the IBC mode is implemented as a block-level coding mode, block matching (BM) is performed at the encoder to find the best block vector (or motion vector) for each CU. Here, the block vector is used to indicate the displacement from the current block to the reference block, which has been reconstructed within the current picture. The luminance block vector of the CU encoded and decoded by IBC has integer precision. The chrominance block vector is also rounded to integer precision. When combined with AMVR, the IBC mode can switch between 1-pixel and 4-pixel motion vector precision. The CU encoded and decoded by IBC is regarded as a third prediction mode in addition to the intra or inter prediction mode. The IBC mode is applicable to CUs whose width and height are both less than or equal to 64 luminance samples. On the encoder side, hash-based motion estimation is performed for IBC. The encoder performs RD checks on blocks with width or height no greater than 16 luma samples. For non-merge mode, a block vector search is first performed using a hash-based search. If the hash search does not return a valid candidate, a local search based on block matching is performed. In hash-based search, the hash key matching (32-bit CRC) between the current block and the reference blocks is extended to all allowed block sizes. The hash key calculation for each position in the current picture is based on 4×4 sub-blocks. For current blocks of larger size, the hash key is determined to match the hash key of the reference block when all hash keys in all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If multiple reference blocks are found whose hash keys match the hash key of the current block, the block vector cost of each matching reference is calculated and the one with the smallest cost is selected. In the block matching search, the search range is set to cover the previous CTU and the current CTU. At CU level, the IBC mode is signaled through a flag, which can be signaled as IBC AMVP mode or IBC Skip / Merge mode as shown below: – IBC skip / merge mode: The merge candidate index is used to indicate which block vector from the list of neighboring candidate IBC codec blocks is used to predict the current block. The merge list consists of spatial candidates, HMVP candidates and pairwise candidates. – IBC AMVP mode: Block vector differences are encoded and decoded in the same way as motion vector differences. The block vector prediction method uses two candidates as predictors, one from the left neighbor and one from the top neighbor (if IBC coded). When either neighbor is not available, the default block vector is used as predictor. A flag is signaled to indicate the block vector predictor index. 2.1.1.1 IBC Reference Area In order to reduce memory consumption and decoder complexity, IBC in VVC only allows the reconstruction of predefined areas, which include the area of ​​the current CTU and a certain area of ​​the left CTU. Figure 4 The reference area of ​​the IBC mode is shown, where each block represents a 64×64 luma sample unit. Depending on the location of the current codec CU location within the current CTU, the following applies: – If the current block falls into the 64×64 block to the upper left of the current CTU, in addition to the samples already reconstructed in the current CTU, the CPR mode can also be used to refer to the reference samples in the lower right 64x64 block of the left CTU. The current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block of the left CTU and the left Reference samples in the top right 64×64 block of the CTU. – If the current block falls into the 64×64 block to the upper right of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the luma position (0, 64) has not been reconstructed relative to the current CTU, the current block can also use the CPR mode to refer to the reference samples in the lower left 64×64 block and the lower right 64×64 block of the left CTU; Otherwise, the current block may also refer to reference samples in the lower right 64×64 block of the left CTU. – If the current block falls into the 64×64 block to the lower left of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the luma position (64, 0) has not been reconstructed relative to the current CTU, the current block can also use the CPR mode to refer to the reference samples in the upper right 64×64 block and the lower right 64×64 block of the left CTU. Otherwise, the current block may also use the CPR mode to refer to the reference samples in the 64×64 block in the lower right corner of the left CTU. – If the current block falls into the 64×64 block to the lower right of the current CTU, only the CPR mode can be used to refer to the samples that have been reconstructed in the current CTU. This restriction allows the IBC mode to be implemented using local on-chip memory for hardware implementation. 2.1.1.2 Interaction between IBC and other codecs The interaction between IBC mode and other inter-frame codec tools in VVC, such as pairwise merge candidates, history-based motion vector predictor (HMVP), combined intra / frame prediction modes (CIIP), merge mode with motion vector difference (MMVD), and geometric partition model (GPM), is as follows: – IBC can be used with pairwise merge candidates and HMVP. A new pairwise IBC merge candidate can be generated by averaging two IBC merge candidates. For HMVP, IBC motions are inserted into the history buffer for future reference. – IBC cannot be used in conjunction with the following interframe tools: Affine Motion, CIIP, MMVD, and GPM. – When DUAL_TREE partitioning is used, IBC is not allowed for chroma codec blocks. Unlike in the HEVC screen content codec extension, the current picture is no longer included as one of the reference pictures in reference picture list 0 for IBC prediction. The motion vector derivation process for IBC mode excludes all neighboring blocks in inter mode and vice versa. The following IBC design aspects are applied: – IBC shares the same process as regular MV merging, including pairwise merging candidates and history-based motion predictors, but TMVP and zero vectors are not allowed since they are invalid for IBC mode. – Separate HMVP buffers (5 candidates each) for legacy MV and IBC. – Block vector constraints are implemented as bitstream consistency constraints, where the encoder needs to ensure that there are no invalid vectors in the bitstream and that merges should not be used if the merge candidate is invalid (out of range or 0). This bitstream consistency constraint is represented by a virtual buffer as described below. – For deblocking, IBC is handled as an inter mode. – If the current block is coded using IBC prediction mode, AMVR does not use quarter pixels; instead, AMVR is signaled to only indicate whether the MV is inter-pixel or 4-integer pixels. - The number of IBC merge candidates may be signaled in the slice header separately from the number of normal, sub-block and geometric merge candidates. The concept of virtual buffer is used to describe the allowable reference area for IBC prediction mode and valid block vector. Denoting the CTU size as ctbSize, the width of the virtual buffer ibcBuf is wIbcBuf=128×128 / ctbSize, and the height hIbcBuf=ctbSize. For example, for a CTU of size 128×128, the size of ibcBuf is also 128×128; and for a CTU of size 64×64, the size of ibcBuf is 256×64; for a CTU of size 32×32, the size of ibcBuf is 512×32. The size of VPDU in each dimension is min(ctbSize, 64), Wv = min(ctbSize, 64). The virtual IBC buffer ibcBuf is maintained as follows. – At the start of decoding each CTU line, flush the entire ibcBuf with invalid value -1. – When decoding the VPDU (xVPDU, yVPDU) relative to the upper left corner of the picture, set ibcBuf[x][y] = -1, where x = xVPDU% wIbcBuf, ..., xVPDU% wIbcBuf + Wv-1; y = yVPDU%ctbSize,…,yVPDU%ctbSize+Wv-1. –After decoding, the CU contains the (x,y) relative to the upper left corner of the picture, set ibcBuf[x%wIbcBuf][y%ctbSize]=recSample[x][y] For a block covering coordinates (x, y), it is valid if the following holds for the block vector bv = (bv[0], bv[1]); otherwise, it is invalid: ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] should not be equal to -1. 2.1.2 Block Differential Pulse Coded Modulation (BDPCM) VVC supports Block Differential Pulse Coded Modulation (BDPCM) for screen content coding. At the sequence level, the BDPCM enable flag is signaled in the SPS; this flag is signaled only when transform skip mode (described in the next section) is enabled in the SPS. When BDPCM is enabled, if the CU size is less than or equal to MaxTsSize×MaxTsSize in terms of luma samples and if the CU is intra-coded, a flag is sent at the CU level, where MaxTsSize is the maximum block size that allows transform skip mode. The flag indicates whether conventional intra-coding or BDPCM is used. If BDPCM is used, the BDPCM prediction direction flag is transmitted to indicate whether the prediction is horizontal or vertical. The block is then predicted using a conventional horizontal or vertical intra prediction process with unfiltered reference samples. The residuals are quantized, and the difference between each quantized residual and its predictor, i.e., the previously coded residual of a neighboring position horizontally or vertically (depending on the BDPCM prediction direction), is coded. For a block of size M (height) × N (width), let r i,j ,0≤i≤M-1,0≤j≤N-1 is the prediction residual. Let Q(r i,j ), 0≤i≤M-1,0≤j≤N-1 represents the residual r i,j BDPCM is applied to the quantized residual values, resulting in a quantized version of The modified M×N array in is predicted from its neighboring quantized residual values. For vertical BDPCM prediction mode, for 0≤j≤(N-1), the following is used to derive For the horizontal BDPCM prediction mode, for 0≤j≤(N-1), the following is used to derive On the decoder side, the above process is reversed to calculate Q(r i,j ), 0≤i≤M-1,0≤j≤N-1, as follows: The inverse quantized residual Q -1 (Q(r i,j )) is added to the intra block prediction value to produce the reconstructed sample value. The predicted quantized residual value is converted to Sent to the decoder. For lossless codec, if slice_ts_residual_coding_disabled_flag is set to 1, the quantized residual values ​​are sent to the decoder using the conventional transform residual codec as described in 2.2.2. For MPM modes for future intra-mode codecs, if the BDPCM prediction direction is horizontal or vertical, respectively, the horizontal or vertical prediction mode is stored for the BDPCM-coded CU, respectively. For deblocking, if the two blocks on both sides of the block boundary are coded and decoded using BDPCM, then the specific block boundary is not deblocked. 2.1.3 Residual Codec for Transform Skip Mode VVC allows transform skip mode for luma blocks of size up to MaxTsSize×MaxTsSize, where the value of MaxTsSize is signaled in the PPS and can be at most 32. When a CU is encoded and decoded in transform skip mode, its prediction residual is quantized and encoded using the transform skip residual encoding and decoding process. This process is modified from the transform coefficient encoding and decoding process described in 2.2.2. In transform skip mode, the residual of the TU is also encoded and decoded in units of non-overlapping sub-blocks of size 4×4. For better coding efficiency, some modifications are made to customize the residual coding and decoding process to the residual signal characteristics. The following summarizes the differences between transform skip residual coding and conventional transform residual coding: - A forward scan order is applied to scan sub-blocks within a transformed block and also scan positions within the sub-blocks; – no signaling of the final (x, y) position; – When all previous flags are equal to 0, coded_sub_block_flag is coded and decoded for each sub-block except the last sub-block; –sig_coeff_flag context modeling uses a simplified template, and the context model of sig_coeff_flag is taken Depends on the top and left neighboring values; – The context model of the abs_level_gt1 flag also depends on the left sig_coeff_flag value and the upper sig_coeff_flag value; – par_level_flag to use only one context model; – Signal additional greater than 3, 5, 7, 9 flags to indicate coefficient levels, with one for each flag context; – Binarization for the remainder values ​​derived using Rice parameters with fixed order = 1; - Determine the context model for the sign flag based on the left and above neighboring values, and parse the sign flag after sig_coeff_flag to keep all context-coded bins together. For each subblock, if coded_subblock_flag is equal to 1 (i.e., there is at least one non-zero quantized residual in the subblock), encoding and decoding of the quantized residual level is performed in three scanning passes (see Figure 5 ): - First scan pass: Encode and decode the validity flag (sig_coeff_flag), the sign flag (coeff_sign_flag), the flag that the absolute level is greater than 1 (abs_level_gtx_flag[0]), and the parity check (par_level_flag). For a given scan position, if sig_coeff_flag is equal to 1, coeff_sign_flag is encoded and decoded, followed by abs_level_gtx_flag[0] (which specifies whether the absolute level is greater than 1). If abs_level_gtx_flag[0] is equal to 1, par_level_flag is additionally encoded and decoded to specify the parity of the absolute level. – Scan pass greater than x: For each scan position where the absolute level is greater than 1, up to four abs_level_gtx_flag[i] are encoded for i=1..4 to indicate whether the absolute level at the given position is greater than 3, 5, 7 or 9. – Remainder scan pass: The absolute level remainder abs_remainder is encoded and decoded in bypass mode. The absolute level remainder is binarized using a fixed Rice parameter value of 1. The binary bits in scan passes #1 and #2 (the first scan pass and greater than x scan passes) are context-coded until the maximum number of context-coded binary bits in the TU has been exhausted. The maximum number of context-coded binary bits in the residual block is limited to 1.75*block_width*block_height, or equivalently, an average of 1.75 context-coded binary bits per sample position. The binary bits in the last scan pass (remainder scan pass) are bypass-coded. The variable RemCbs is first set to the maximum number of context-coded binary bits for the block and is reduced by 1 each time a context-coded binary bit is coded. When RemCcbs is greater than or equal to 4, the context-coded binary bits are used to encode and decode the syntax elements in the first codec pass, including sig_coeff_flag, coeff_sign_flag, abs_level_gt1_flag, and par_level_flag. If RemCcbs becomes smaller than 4 when encoding and decoding the first pass, the remaining coefficients that have not been encoded in the first pass are encoded and decoded in the remainder scanning pass (pass#3). After the first pass of encoding and decoding is completed, if RemCcbs is greater than or equal to 4, the context-coded binary bits are used to encode and decode the syntax elements in the second pass of encoding and decoding, including abs_level_gt3_flag, abs_level_gt5_flag, abs_level_gt7_flag, and abs_level_gt9_flag. If RemCcbs becomes less than 4 when encoding and decoding the second pass, the remaining coefficients that have not been encoded and decoded in the second pass are encoded and decoded in the remainder scan pass (pass#3). Figure 5 The transform skip residual coding process is shown. The stars mark the positions where the context coded bins are exhausted, at which point all remaining bins are coded using bypass coding. In addition, for blocks not coded in BDPCM mode, a horizontal mapping mechanism is applied to transform skipped residual coding until the maximum number of context-coded binary bits has been reached. Horizontal mapping uses the top and left neighboring coefficient levels to predict the current coefficient level in order to reduce signaling costs. For a given residual position, denote absCoeff as the absolute coefficient level before mapping, and absCoeffMod as the coefficient level after mapping. Let X0 denote the absolute coefficient level of the left neighboring position, and let X1 denote the absolute coefficient level of the upper neighboring position. Horizontal mapping is performed as follows: pred=max(X0,X1); if(absCoeff == pred) absCoeffMod = 1; else absCoeffMod = (absCoeff <pred)?absCoeff+1:absCoeff. The absCoeffMod value is then encoded as described above.After all context-decoded bins have been exhausted, horizontal mapping is disabled for all remaining scan positions in the current block. 2.1.4 Palette Mode In VVC, palette mode is used for picture content encoding and decoding in all chroma formats supported in 4:4:4 profile (i.e., 4:4:4, 4:2:0, 4:2:2, and monochrome). When palette mode is enabled, if the CU size is less than or equal to 64×64, a flag is transmitted at the CU level, and the number of samples in the CU is greater than 16 to indicate whether palette mode is used. Considering that applying palette mode on small CUs introduces insignificant codec gain and brings additional complexity on small blocks, palette mode is disabled for CUs less than or equal to 16 samples. A palette-encoded codec unit (CU) is treated as a prediction mode different from intra-prediction, inter-prediction, and intra-block copy (IBC) modes. If palette mode is used, the sample values ​​in a CU are represented by a set of representative color values. This set is called a palette. For positions with sample values ​​close to the palette colors, the palette index is signaled. Samples outside the palette can also be specified by signaling escape symbols. For samples within a CU coded and decoded using escape symbols, their component values ​​are signaled directly using (possibly) quantized component values. This is done in Figure 6 The quantized escaped symbols are binarized using a fifth-order exponential Golomb binarization process (EG5). For palette encoding and decoding, the palette predictor is maintained. For the non-wavefront case, the palette predictor is initialized to 0 at the beginning of each stripe. For the WPP case, the palette predictor at the beginning of each CTU row is initialized to the predictor derived from the first CTU in the previous CTU row, so that the initialization scheme between the palette predictor and CABAC synchronization is unified. For each entry in the palette predictor, a reuse flag is signaled to indicate whether it is part of the current palette in the CU. The reuse flag is sent using a run length codec of zero. Thereafter, the number of new palette entries and the component values ​​of the new palette entries are signaled. After encoding the palette-encoded CU, the palette predictor will be updated with the current palette, and entries from the previous palette predictor that are not reused in the current palette will be added to the end of the new palette predictor until the maximum allowed size is reached. An escape flag is signaled for each CU to indicate whether there is an escape symbol in the current CU. If there is an escape symbol, the palette table is expanded by one and the last index is assigned as the escape symbol. In a manner similar to the coefficient groups (CGs) used in transform coefficient coding, a CU coded with palette mode is divided into multiple line-based coefficient groups, each consisting of m samples (i.e., m=16), where the index run of the escape mode, the palette index value, and the quantized color are encoded / parsed sequentially for each CG. As in HEVC, horizontal or vertical traversal scanning can be applied to scan samples, such as Figure 7 as shown in . Figure 7 Sub-block based index map scanning for a palette is shown, on the left for horizontal scanning and on the right for vertical scanning. The encoding and decoding order for the palette run encoding and decoding in each fragment is as follows: For each sample position, a context encoded binary bit run_copy_flag=0 is signaled to indicate whether the pixel has the same mode as the previous sample position, that is, whether the previously scanned sample and the current sample are both of run type COPY_ABOVE, or whether the previously scanned sample and the current sample both have run type INDEX and the same index value. Otherwise, run_copy_flag=1 is signaled. If the current sample has a different mode from the previous sample, then a context encoded binary bit copy_above_palette_indices_flag is signaled to indicate the run type of the current sample, that is, INDEX or COPY_ABOVE. Here, if the sample is in the first row (horizontal traversal scan) or the first column (vertical traversal scan), the decoder does not have to parse the run type because the INDEX mode is used by default. In the same way, if the previously parsed run type is COPY_ABOVE, the decoder does not have to parse the run type. After palette run encoding of samples in one encoding pass, index values ​​(for INDEX mode) and quantized escape colors are grouped and encoded using CABAC bypass encoding in another encoding pass. This separation of context encoding binary bits and bypass encoding binary bits can improve throughput within each line CG. For slices with dual luma / chroma trees, the palette is applied separately to luma (Y component) and chroma (Cb and Cr components), where the luma palette entries contain only Y values, and the chroma palette entries contain both Cb and Cr values. For slices of a single tree, the palette is applied jointly on the Y, Cb, Cr components, i.e., each entry in the palette contains Y, Cb, Cr values, unless when a CU is encoded using local dual-tree encoding, in which case the encoding of luma and chroma is handled separately. In this case, if the corresponding luma blocks or chroma blocks are encoded using palette mode, their palettes are applied in a manner similar to the dual-tree case (this is relevant for non-4:4:4 codecs and will be further explained in 2.1.4.1). For slices decoded with dual-tree codec, the maximum palette predictor size is 63, and the maximum palette table size for the codec of the current CU is 31. For slices decoded with dual-tree codec, the maximum predictor and palette table sizes are halved, i.e., for each of the luma palette and chroma palette, the maximum predictor size is 31 and the maximum table size is 15. For deblocking, palette-coded blocks on the side of a block boundary are not deblocked. 2.1.4.1 Palette Mode for Non-4:4:4 Content The palette modes in VVC are supported for all chroma formats in a similar manner as the palette modes in HEVC SCC. For non-4:4:4 content, the following customizations apply: 1. When signaling an escape value for a given sample position, if that sample position has only a luma component but no chroma components due to chroma subsampling, then only the luma escape value is signaled. This is the same as in HEVCSCC. 2. For local double-tree blocks, the palette pattern is the same as the palette applied to a single T-block with two exceptions Patterns apply to blocks in the same way: a. The process of palette predictor updating is slightly modified as follows. Since the local dual-tree block contains only luminance (or chroma) components, so the predictor update process uses the signaled values ​​of the luma (or chroma) components and fills in the "missing" chroma (or luma) components by setting them to default values ​​(1<<(component bit depth - 1)). b. The maximum palette predictor size remains at 63 (because the slices are encoded and decoded using a single tree), but the maximum palette table size for luma / chroma blocks remains at 15 (because the blocks are encoded and decoded using separate palettes). 3. For palette mode in monochrome format, the number of color components in a palette-encoded block is set to 1 instead of 3. 2.1.4.2 Encoder Algorithm for Palette Mode On the encoder side, the following steps are used to generate the palette table of the current CU. 1. First, to derive the initial entries in the palette table of the current CU, a simplified K-means clustering is applied. Initialize the palette table of the current CU to an empty table. For each sample position in the CU, calculate the SAD between this sample and each palette table entry, and obtain the minimum SAD among all palette table entries. If the minimum SAD is less than the predefined error limit errorLimit, the current sample is clustered with the palette table entry with the minimum SAD. Otherwise, a new palette table entry is created. The threshold errorLimit is QP-dependent and is retrieved from a lookup table containing 57 elements covering the entire QP range. After all samples of the current CU have been processed, the initial palette entries are sorted according to the number of samples clustered with each palette entry, and any entries after the 31st entry are discarded. 2. In the second step, the initial palette table colors are adjusted by considering two options: using the centroid of each cluster from step 1 or using one of the palette colors in the palette predictor. The option with the lower rate-distortion cost is selected as the final color of the palette table. If a cluster has only a single sample and the corresponding palette entry is not in the palette predictor, the corresponding sample is converted to an escape symbol in the next step. 3. The resulting palette table contains some new entries from the centroids of the clusters in step 1, and some entries from the palette predictors. Therefore, the table is reordered again so that all new entries (i.e., The centroid) is placed at the beginning of the table, followed by the entries from the palette predictor. Given the palette table of the current CU, the encoder selects the palette index for each sample position in the CU. For each sample position, the encoder checks the RD cost of all index values ​​corresponding to the palette table entry, as well as the index representing the escape symbol, and selects the index with the minimum RD cost using the following equation. RD cost = distortion × (isChroma? 0.8:1) + lambda × bypassed coded bits (2-5) After determining the index map for the current CU, each entry in the palette table is checked to see if it is used by at least one sample position in the CU. Any unused palette entry will be removed. After deciding the index map for the current CU, the trellis RD optimization is applied to find the best values ​​of run_copy_flag and run type for each sample position by comparing the RD costs of three options: same as the previously scanned position, run type COPY_ABOVE, or run type INDEX. When calculating the SAD value, the sample values ​​are scaled down to 8 bits unless the CU is encoded or decoded in lossless mode, in which case the actual input bit depth is used to calculate the SAD. In addition, in the case of lossless codecs, only the ratio is used in the above rate-distortion optimization step (because lossless codecs do not cause distortion). 2.1.5 Adaptive Color Transformation In the HEVC SCC extension, Adaptive Color Transform (ACT) is applied to reduce the redundancy between the three color components in the 444 chroma format. ACT is also adopted in the VVC standard to enhance the codec efficiency of the 444 chroma format codec. As in HEVC SCC, ACT performs an in-loop color space conversion in the prediction residual domain by adaptively converting the residual from the input color space to the YCgCo space. Figure 8A decoding flow chart for applying ACT is shown. Two color spaces are adaptively selected by signaling an ACT flag at the CU level. When the flag is equal to 1, the residual of the CU is encoded and decoded in the YCgCo space; otherwise, the residual of the CU is encoded and decoded in the original color space. In addition, similar to the HEVC ACT design, for inter and IBc CUs, ACT is enabled only when there is at least one non-zero coefficient in the CU. ACT is only enabled when the chroma component selects the same intra prediction mode of the luminance component (i.e., DM mode). 2.1.5.1ACT Mode In the HEVC SCC extension, ACT supports both lossless and lossy codecs based on the lossless flag (i.e., cu_transquant_bypass_flag). However, there is no flag in the bitstream to indicate whether lossy or lossless codec is applied. Therefore, the YCgCo-R transform is applied as ACT to support both lossy and lossless cases. The YCgCo-R reversible color transform is shown below. Since the YCgCo-R transform is not normalized. In order to compensate for the dynamic range change of the residual signal before and after the color transform, the QP adjustment of (-5, 1, 3) is applied to the transform residuals of the Y, Cg and Co components respectively. The adjusted quantization parameter only affects the quantization and inverse quantization of the residual in the CU. For other encoding and decoding processes (such as deblocking), the original QP is still applied. Additionally, because the forward and inverse color transforms require access to the residuals of all three components, ACT mode is always disabled for single tree partitioning and ISP mode, where the prediction block sizes for different color components are different. When ACT is applied, transform skip (TS) and block differential pulse codec modulation (BDPCM) extended to code chroma residuals are also enabled. 2.1.5.2 ACT Fast Encoding Algorithm To avoid brute force RD searches in both the original and converted color spaces, the following fast encoding algorithm is applied in the VTM reference software to reduce encoder complexity when ACT is enabled. – The order of RD checking for enabling / disabling ACT depends on the original color space of the input video. For RGB video, RD cost for ACT mode is checked first; for YCbCr video, RD cost for non-ACT mode is checked first. RD cost for the second color space is checked only if there is at least one non-zero coefficient in the first color space. – When a CU is obtained through different partitioning paths, the same ACT enable / disable decision is reused. Specifically, when the CU is encoded and decoded for the first time, the selected color space used to encode and decode the residual of a CU will be stored. Then, when the same CU is obtained by another partitioning path, instead of checking the RD cost of the two spaces, the stored color space decision will be reused directly. – The RD cost of the parent CU is used to decide whether to check the RD cost of the second color space of the current CU. For example, if the RD cost of the first color space is less than the RD cost of the second color space for the parent CU, the second color space is not checked for the current CU. – To reduce the number of tested codec modes, the selected codec modes are shared between the two color spaces. Specifically, for intra mode, the pre-selected intra mode candidates according to SATD-based intra mode selection are shared between the two color spaces. For inter and IBC modes, only one block vector search or motion estimation is performed. Block vectors and motion vectors are shared by the two color spaces. 2.1.6 Intra-frame template matching Intra Template Matching Prediction (Intra TMP) is a special intra prediction mode that copies the best prediction block from the reconstructed part of the current frame, whose L-shaped template matches the current template. For a predefined search range, the encoder searches for the template that is most similar to the current template in the reconstructed part of the current frame and uses the corresponding block as the prediction block. The encoder then signals the use of this mode and performs the same prediction operation on the decoder side. By combining the L-shaped causal neighbors of the current block with Fig. 9 The prediction signal is generated by matching another block in a predefined search area in the image to generate a prediction signal, the predefined search area including: R1: current CTU; R2: upper left CTU; R3: above CTU; R4: Left CTU. SAD is used as the cost function. In each region, the decoder searches for the template with the minimum SAD relative to the current region and uses its corresponding block as the prediction block. The size of all regions (SearchRange_w, SearchRange_h) is proportional to the block size (BlkW, BlkH) with a fixed number of SAD comparisons per pixel. That is: SearchRange_w=a*BlkW SearchRange_h=a*BlkH Where 'a' is a constant that controls the gain / complexity tradeoff. In practice, 'a' is equal to 5. The intra template matching tool is enabled on width and height for CUs of size less than or equal to 64. This maximum CU size for intra template matching is configurable. When DIMD is not used for the current CU, the intra template matching prediction mode is signaled at the CU level through a dedicated flag. 2.1.7 IBC with Template Matching (IBC-TM) In ECM-5.0, template matching with IBC is used for both IBC merge mode and IBC AMVP mode. Compared to the merge list used by the regular IBC merge mode, the IBC-TM merge list has been modified so that candidates are selected according to a pruning method with motion distances between candidates in the regular TM merge mode. The realization of ending zero motion (which is non-sensing with respect to intra coding) has been replaced by motion vectors of the left (-W, 0), top (0, -H), and top-left (-W, -H), where W is the width of the current CU and H is the height of the current CU. In IBC-TM merge mode, the selected candidates are refined using template matching methods before RDO or decoding process.IBC-TM merge mode has competition with regular IBC merge mode and signals the TM merge flag. In IBC-TM AMVP mode, up to 3 candidates are selected from the IBC-TM merge list. Each of these 3 selected candidates is refined using a template matching method and ranked according to the template matching cost it incurs. Only the first two candidates are then typically considered in the motion estimation process. Template matching refinement for both IBC-TM merge mode and AMVP mode is very simple because IBC motion vectors are constrained to be (i) integers and (ii) within the reference region as shown in Fig. 10. Therefore, in IBC-TM merge mode, all refinements are performed with integer precision, and in IBC-TM AMVP mode, they are performed with integer or 4-pixel precision depending on the AMVR value. Such refinement is only accessed for samples that are not interpolated. In both cases, the refined motion vectors and the template used in each refinement step must obey the reference region constraints. 2.1.8 Expanded HMVP Table for IBC In ECM-5.0, the HMVP table size for IBC is increased to 25. After up to 20 IBC merge candidates are derived using full pruning, they are re-ranked together. After re-ranking, the top 6 candidates with the lowest template matching cost are selected as the final candidates in the IBC merge list. 2.1.9 Block vector difference binarization In ECM-4.0, the block vector difference (BVD) shares the same binarization method as the motion vector difference (MVD). For each component greater than 0, a flag greater than 1 is signaled, and then the residual amplitude of the bypass codec is binarized using EG1 code. In ECM-5.0, the greater than 1 flag is removed and the first 5 bins of the EG1 prefix are context coded, all other bins are still bypass coded. 2.1.10 Reconstruction Reordering IBC (RRIBC) At the JVET-Z conference, the reconstruction reordering IBC (RR-IBC) mode for screen content video coding and decoding was proposed. When RR-IBC is applied, the 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, and the prediction block is derived without flipping. On the decoder side, the reconstructed block is flipped back to restore the original block. For RR-IBC codec blocks, two flipping methods (horizontal flip and vertical flip) are supported. A syntax flag is first signaled for the IBC AMVP codec block, indicating whether the reconstruction is flipped, and if it is flipped, another flag is further signaled to specify the flip type. For IBC merging, the flip type is inherited from the neighboring block without syntax signaling. Taking into account horizontal or vertical symmetry, the current block and the reference block are usually aligned horizontally or vertically. Therefore, when horizontal flipping is applied, the vertical component of BV is not signaled and is inferred to be equal to 0. Similarly, when vertical flipping is applied, the horizontal component of BV is not signaled and is inferred to be equal to 0. To better exploit the symmetry property, a flip-aware BV adjustment method is applied to refine the block vector candidates. Fig.11A shows an example of BV adjustment for horizontal flipping, and Fig. 11B An example of BV adjustment for vertical flipping is shown. Fig.11A and Fig. 11B As shown, (x nbr， y nbr ) and (x cur ,y cur ) represent the coordinates of the center samples of the neighboring blocks and the current block, BV nbr and BV cur Represents the BV of the neighboring block and the current block respectively. BV is not inherited directly from the neighboring block, but when the neighboring block is encoded and decoded with horizontal flipping, BV cur The horizontal component of the motion offset is added to BV nbr The horizontal component (expressed as BV nbr h ) is calculated, that is, BVcur h =2(x nbr -x cur )+BV nbr h Similarly, in the case where the neighboring blocks are coded with vertical flipping, BV cur The vertical component of the motion offset is added to BV nbr The vertical component (expressed as BV nbr v ) is calculated, that is, BV cur v =2(y nbr -y cur )+BV nbr v . 2.1.11 IBC has a merge mode with block vector differences In the present disclosure, an IBC merge mode with block vector difference (also referred to as IBC-MBVD) is introduced. Similar to the conventional MMVD mode, in IBC-MBVD, after an IBC base candidate is selected, the IBC base candidate is further refined by the signaled BVD information. In method #1, the distance set is {1 pixel, 2 pixels, 4 pixels, 8 pixels, 16 pixels, 32 pixels, 48 ​​pixels, 64 pixels, 80 pixels, 96 pixels, 112 pixels, 128 pixels}, and the BVD directions are two horizontal directions and two vertical directions. In method #2, the distance set is {1 pixel, 2 pixels, 4 pixels, 8 pixels, 12 pixels, 16 pixels, 24 pixels, 32 pixels, 40 pixels, 48 ​​pixels, 56 pixels, 64 pixels, 72 pixels, 80 pixels, 88 pixels, 96 pixels, 104 pixels, 112 pixels, 120 pixels, 128 pixels}, and the BVD directions are two horizontal directions and two vertical directions. For both methods, the base candidate is selected from the reordered IBC merge list. And all possible MBVD refinement positions (12×4 for method #1 and 20×4 for method #2) for each base candidate are reordered based on the SAD cost between the template (one row above the current block and one column to the left of the current block) and the template's reference for each refinement position. Finally, the top 1 / 4 refinement positions with the lowest template SAD cost are kept as available positions and are therefore used for MBVD index encoding and decoding. 2.2 Sample Reordering 2.2.1 Reordering of Reconstructed Samples The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow sense. In addition, these solutions can be combined in any way. In the following disclosure, a block may refer to a codec block (CB), a codec unit (CU), a prediction block (PB), a prediction unit (PU), a transform block (TB), a transform unit (TU), a sub-block, a sub-CU, a codec tree unit (CTU), a codec tree block (CTB), or a codec group (CG). In the following disclosure, a region may refer to any video unit, such as a picture, a slice, or a block. A region may also refer to a non-rectangular area, such as a triangle. In the following disclosure, W and H represent the width and height of the rectangular area mentioned. 1. It is proposed that samples in a region can be reordered. a. The reordering of samples can be defined as follows: Assume that the position (x, y) in the region before reordering The sample at position (x, y) is denoted as S(x, y), and the sample at position (x, y) in the region after reordering is denoted as R(x, y). It is required that R(x, y) = S(f(x, y), g(x, y)), where (f(x, y), g(x, y)) is the position in the region, and f and g are two functions. i. For example, it is required that there exists at least one position (x, y) such that ((x, y), g(x, y)) is not equal to (x, y). y). b. The samples in the area to be reordered can be: i. The original sample before encoding; ii. Prediction sample; iii. Reconstruct the sample; iv. Transformed samples (transformation coefficients); v. Samples before inverse transformation (coefficients before inverse transformation); vi. Samples before deblocking filtering; vii. Samples after deblocking filtering; viii. Samples before SAO processing; ix. Samples after SAO processing; x. Samples before ALF processing; xi. Samples after ALF processing; xii. Samples before post-processing; xiii. Samples after post-processing. c. In one example, reordering may be applied in more than one stage. i. For example, at least two of the samples listed in item 1.b above may be reordered. 1) For example, different re-ranking methods can be applied to the two samples. 2) For example, the same re-ranking method can be applied to both samples. d. In one example, the reordering may be a horizontal flip. For example, f(x, y) = Px, g(x, y) = y. For example, P = W-1. e. In one example, the reordering may be a vertical flip. For example, f(x, y) = x, g(x, y) = Qy. For example, Q = H-1. f. In one example, the reordering may be a horizontal-vertical flip. For example, f(x, y) = Px, g(x, y) = Qy. For example, P = W-1 and Q = H-1. g. In one example, the reordering may be a shift. For example, f(x, y) = (P + x) % W, g(x, y) = (Q + y) % H, where P and Q are integers. h. In one example, the reordering may be a rotation. i. In one example, there exists at least one (x, y) such that (x, y) is equal to (f(x, y), g(x, y)). j. In one example, whether and / or how to reorder samples can be signaled from the encoder to the decoder, e.g., in the SPS / sequence header / PPS / picture header / APS / slice header / sub-picture / tile / CTU line / CTU / CU / PU / TU. i. For example, a first flag is signaled to indicate whether reordering is applied. 1) For example, the first flag may be encoded and decoded using context encoding and decoding. ii. For example, a second syntax element (eg, a flag) is signaled to indicate which reordering method (eg, horizontal flip or vertical flip) is used. 1) For example, the second syntax element is signaled only if it is indicated that reordering is applied. 2) For example, context coding may be used to codec the second syntax element. 2. Propose whether and / or how to reorder samples may depend on codec information. a. In one example, whether and / or how to reorder samples may be derived depending on codec information at picture level / slice level / CTU level / CU level / PU level / TU level. b. In one example, the codec information may include: i. The size of the area. ii. The codec mode of the region (e.g., inter, intra, or IBC). iii. Motion information (such as motion vectors and reference indices). iv. Intra prediction mode (eg angular intra prediction mode, planar or DC). v. Inter prediction modes (such as affine prediction, bi-directional prediction / uni-directional prediction, merge mode, combined inter-intra prediction (CIIP), merge with motion vector difference (MMVD), temporal motion vector prediction (TMVP), sub-TMVP). vi. Quantization parameter (QP). vii. Codec tree segmentation information such as codec tree depth. viii. Color format and / or color components. 3. It is proposed that at least one parsing or decoding process other than the reordering process may depend on whether and / or how the samples are reordered. a. For example, a syntax element may be conditionally signaled based on whether or not reordering is applied. b. For example, different scan orders may be used based on whether and / or how the samples are reordered. c. For example, deblocking filtering may be used based on whether and / or how samples are reordered / SAO / ALF. 4. In one example, the samples may be processed by at least one auxiliary process before or after the resampling process. Some possible auxiliary processes may include: (combinations may be allowed) a. For example, at least one sample may be added by an offset. b. For example, at least one sample may be multiplied by a factor. c. For example, at least one sample may be cropped. d. For example, at least one sample may be filtered. e. For example, at least one sample X can be modified to T(X), where T is a function. 5. In one example, for a block encoded and decoded in IBC mode a. For example, a first flag is signaled to indicate whether the reconstructed samples should be reordered. i. For example, the first flag may be encoded and decoded using context encoding and decoding. b. For example, a second flag may be signaled to indicate whether the reconstructed samples should be flipped horizontally or vertically. i. For example, the second flag is signaled only when the first flag is true. ii. For example, the second flag may be encoded and decoded using context encoding and decoding. 2.2.2 Sample Reordering - Application Conditions and Interaction with Other Processes The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow sense. In addition, these solutions can be combined in any way. The term “video unit” or “codec unit” may refer to a picture, a slice, a tile, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. The term "block" may refer to a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. Note that the terms mentioned below are not limited to the specific terms defined in existing standards. Any changes in encoding tools are also applicable. 1. Regarding the application conditions of sample reordering (eg, the first problem and related problems), the following method is proposed. a. Whether the reordering process is applied to the reconstructed / original / prediction block may depend on the coded information of the video unit. a. For example, it may depend on the prediction method. b. For example, if the video unit is encoded with one or more modes / techniques listed below, then the reordering process may be applied to the video unit. Otherwise, the reordering process is disabled. i. Intra-block copy (also called IBC). ii. Current Picture Reference (also called CPR). iii. Intra-template matching (also called Intra-TM). iv. IBC template matching (or IBC mode based on template matching). v. Merge-based encoding and decoding. vi. Codec based on AMVP. c. For example, it may depend on the block dimensions (such as block width and / or height). d. For example, if the dimensions W×H of the video unit meet one or more of the rules listed below, then the reordering process may be applied to the video unit. Otherwise, the reordering process is disabled. i. If W>=T1 and / or H>=T2. ii. If W <= T1 and / or H <= T2. iii. If W>T1 and / or H>T2. iv. If W<T1 and / or H<T2. v.If W×H>=T. vi. If W×H>T. vii. If W×H<=T. viii.If W×H<T. 2. Regarding which kinds of samples are reordered and the interaction with other processes (e.g., the second question and related questions), the following method is proposed. a. A possible sample reordering method can refer to one or more of the following processes: a. The shaped domain samples of the video unit (eg, obtained based on the LMCS method) may be reordered. i. For example, the shaped domain luma samples of a video unit (eg, obtained by luma mapping based on the LMCS method) may be reordered. b. The original domain (rather than the LMCS reshaped domain) samples of the video unit can be reordered. i. For example, the original domain chroma samples of a video unit may be reordered. ii. For example, the original domain luma samples of a video unit may be reordered. c. The reconstructed samples of the video unit can be reordered. i. For example, the reconstructed samples of a video unit may be reordered immediately after adding the decoded residual to the prediction. ii. For example, the integer-domain luma reconstruction samples of a video unit may be reordered. iii. For example, the raw domain luma reconstruction samples of a video unit may be reordered. iv. For example, the original domain chroma reconstructed samples of a video unit may be reordered. d. The inverse brightness mapping of the LMCS process may be applied based on the reordered reconstructed samples. e. A loop filtering process (eg, luma / chroma bilateral filter, luma / chroma SAO, CCSAO, luma / chroma ALF, CCALF, etc.) may be applied based on the reordered reconstructed samples. i. For example, the loop filter process may be applied based on reconstructed samples reordered in the original domain (rather than the LMCS shaping domain). f. Distortion calculations (eg, SSE calculations between original samples and reconstructed samples) may be based on the reordered reconstructed samples. i. For example, the distortion calculation can be based on the reconstructed samples reordered from the original domain. g. The original samples of a video unit can be reordered. i. For example, the integer-domain raw luma samples of a video unit may be reordered. ii. For example, the original domain raw luma samples of a video unit may be reordered. iii. For example, the original domain raw chroma samples of a video unit may be reordered. iv. For example, the residual can be generated by subtracting the prediction from the reordered original samples. h. The prediction samples of the video unit can be reordered. i. For example, the reordering process for prediction samples may be performed immediately after the motion compensation process. ii. For example, sign prediction may be applied based on the reordered prediction samples of the video unit. General Aspects 3. Whether and / or how to apply the method disclosed above may be signaled at the sequence level / picture group level / picture level / slice level / tile group level, for example in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / tile group header. 4. Whether and / or how to apply the above disclosed methods can be signaled in PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / tile / sub-picture / other kinds of areas containing more than one sample or pixel. 5. Whether and / or how to apply the above disclosed method may depend on the coded information, such as block size, color format, single tree / dual tree partitioning, color component, slice / picture type. 2.2.3 Sample Reordering - Sample Reordering, Signaling and Storage The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow way. In addition, these solutions can be combined in any way. The term “video unit” or “codec unit” may refer to a picture, a slice, a tile, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. The term "block" may refer to a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. Note that the terms mentioned below are not limited to the specific terms defined in existing standards. Any changes in encoding tools are also applicable. 1. Regarding the signaling of sample reordering (eg, the first problem and related problems), the following method is proposed. a. For example, at least one new syntax element (e.g., flag, index, variable, parameter, etc.) may be signaled Use of sample reordering to specify video units. a. For example, assuming a particular prediction method is used for a video unit, at least one new syntax element (eg, a flag) may be further signaled to specify the use of sample reordering. b. For example, assuming that the intra template matching usage flag specifies that the video unit is coded by intra template matching, a first new syntax element (eg, a flag) may be further signaled to specify the use of sample reordering for the video unit coded by intra template matching. c. For example, assuming that the IBC amvp flag specifies that the video unit is coded by IBC amvp, a first new syntax element (eg, a flag) may be further signaled to specify the use of sample reordering for the video unit coded by IBC amvp. d. For example, assuming that the IBC merge flag specifies that the video unit is coded by IBC merge, a first new syntax element (eg, a flag) may be further signaled to specify the use of sample reordering for the IBC merge coded video unit. b. In addition, for example, if the first new syntax element specifies that sample reordering is used for a video unit encoded and decoded by a specific prediction method, a second new syntax element (e.g., a flag) may be further signaled to specify which reordering method (e.g., horizontal flipping or vertical flipping) is used for the video unit. c. For example, a single new syntax element (e.g., parameter or variable or index) may be signaled to a video unit, rather than multiple concatenated syntax elements, specifying the type of reordering applied to the video unit (e.g., no flip, horizontal flip, or vertical flip). a. For example, assuming that the intra template matching usage flag specifies that the video unit is encoded and decoded by intra template matching, a new syntax element (e.g., index) can be further signaled to specify the type of reordering of samples of the video unit encoded and decoded by intra template matching. b. For example, assuming that the IBC amvp flag specifies that the video unit is coded by IBC amvp, a new syntax element (eg, index) may be further signaled to specify the type of sample reordering for the video unit coded by IBC amvp. c. For example, assuming that the IBC merge flag specifies that the video unit is coded by IBC merge, a new syntax element (eg, index) may be further signaled to specify the type of sample reordering for the video unit coded by IBC merge. d. Additionally, for example, a new syntax element (eg, index) equal to 0 specifies that sample reordering is not used; equal to 1 specifies that sample reordering method A is used; equal to 2 specifies that sample reordering method B is used; and so on. d. For example, one or more syntax elements related to sample reordering may be context encoded and decoded. a. For example, the context may be based on neighboring block / sample coding information (eg, availability, prediction mode, whether merge coded, whether IBC coded, whether sample reordering is applied, which sample reordering method is used, etc.). e. Alternatively, for example, instead of signaling whether to perform sample reordering and / or which reordering method to use for a video unit, some (or all) of these steps may be determined based on predefined rules (without signaling). a. For example, the predefined rules may be based on information about neighboring block / sample codecs. b. For example, assuming that the IBC merge flag specifies that the video unit is encoded and decoded via IBC merging, a process may be performed to determine whether and how to perform reordering based on predefined rules / processes. i. Alternatively, for example, assume that the first new syntax element specifies sample reordering for a video unit, however, instead of further signaling the reordering method, how to reorder is determined based on a predefined rule / procedure (no signaling). ii. Alternatively, for example, whether to perform reordering may be determined implicitly based on a predefined rule / process, but how to reorder may be signaled. c. For example, assuming that the IBC amvp flag specifies that the video unit is coded by IBC amvp, a process can be performed to determine whether and how to perform reordering based on predefined rules / processes. i. Alternatively, for example, assuming that the first new syntax element specifies sample reordering for a video unit, however, instead of further signaling the reordering method, how can the reordering be performed based on a predefined rule / procedure (without signaling) to determine how to reorder. ii. Alternatively, for example, whether to perform reordering may be determined implicitly based on a predefined rule / process, but how to reorder may be signaled. d. For example, assuming that the intra template matching flag specifies that the video unit is encoded by IBC merging, a process can be performed to determine whether and how to perform reordering based on predefined rules / processes. i. Alternatively, for example, assuming that the first new syntax element specifies sample reordering for a video unit, however, instead of further signaling the reordering method, how can the reordering be performed based on a predefined rule / procedure (without signaling) to determine how to reorder. ii. Alternatively, for example, whether to perform reordering may be determined implicitly based on a predefined rule / process, but how to reorder may be signaled. f. For example, whether to perform reordering and / or how to reorder can be inherited from the encoded and decoded blocks. a. For example, it may be inherited from an adjacent spatially neighboring block. b. For example, it may be inherited from a non-adjacent spatially neighboring block. c. For example, it may be inherited from a history-based motion table such as some HMVP table. d. For example, it may be inherited from the temporal motion candidate. e. For example, it can be inherited based on the IBC merge candidate list. f. For example, it can be inherited based on the IBC amvp candidate list. g. For example, it can be inherited based on a generated motion candidate list / table. h. For example, in case a video unit is encoded and decoded via IBC merge mode, sample reordering inheritance may be allowed. i. For example, in case a video unit is encoded and decoded by IBC AMVP mode, sample reordering inheritance may be allowed. j. For example, in the case where a video unit is encoded and decoded via intra template matching mode, sample reordering inheritance may be allowed. 2. With regard to the storage of sample reordering states (e.g., second and related issues), the following method is proposed: a. For example, information on whether and / or how to reorder video units may be stored. a. For example, the stored information can be used for encoding and decoding of future video units. b. For example, this information may be stored in a buffer. i. For example, a buffer can be a line buffer, a table, more than one line buffer, a picture buffer, a compressed picture buffer, a temporal buffer, etc. c. For example, this information may be stored in a historical motion vector table (such as a HMVP table). b. For example, coding information (e.g., whether sample reordering is applied, which sample reordering method is used, block availability, prediction mode, whether merge coded or IBC coded, etc.) may be stored for deriving the context of the sample reordering syntax element. General Aspects 3. Whether and / or how to apply the method disclosed above can be applied at the sequence level / picture group level / picture level / strip level / Signaled at tile group level, for example in sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / tile group header. 4. Whether and / or how to apply the above disclosed methods can be signaled in PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / tile / sub-picture / other kinds of regions containing more than one sample or pixel. 5. Whether and / or how to apply the above disclosed method may depend on the coded information, such as block size, color format, single / dual tree partitioning, color component, slice / picture type. 2.2.4 Sample Reordering - Motion List Generation, Implicit Derivation, and How to Reorder The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow way. In addition, these solutions can be combined in any way. The term “video unit” or “codec unit” may refer to a picture, a slice, a tile, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. The term "block" may refer to a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. Note that the terms mentioned below are not limited to the specific terms defined in existing standards. Any changes in codec tools are also applicable. 1. Regarding motion candidate list generation for sample reordering (eg, the first problem and related problems), the following method is proposed. b. For example, the IBC merge motion candidate list can be used for both the regular IBC merge mode and the sample reordering based IBC merge mode. c. For example, the IBC amvp motion prediction candidate list can be used for both the regular IBC amvp mode and the sample reordering based IBC amvp mode. d. For example, for a target video unit using sample reordering codec, the new motion (prediction) A candidate list is generated. a. For example, the new candidate list may only consider motion candidates that utilize the same reordering method as that of the target video unit. b. For example, the new candidate list may only consider motion candidates that utilize sample reordering codecs (but regardless of the type of sample reordering method). c. Alternatively, a new candidate list may be generated without considering the sample reordering method for each motion candidate. d. For example, non-adjacent motion candidates may be inserted into a new candidate list. i. For example, non-adjacent candidates utilizing sample reordering (but regardless of the type of sample reordering method) may be inserted. ii. For example, non-adjacent candidates of the same reordering method as that of the target video unit may be inserted. iii. For example, non-adjacent candidates may be inserted regardless of whether a sample re-ranking method is applied to the candidates. e. For example, new motion candidates may be generated according to certain rules and inserted into the new candidate list. i. For example, the rules can be based on an averaging process. ii. For example, the rules can be based on the editing process. iii. For example, the rules can be based on a scaling process. e. For example, the motion (prediction) candidate list generation for the target video unit may depend on the reordering method. a. For example, a reordering method associated with each motion candidate (from spatial or temporal domain or history table) may be inserted into a list, whether or not the target video unit will be encoded with sample reordering. b. For example, if the target video unit is to be encoded with sample reordering, only those motion candidates (from spatial or temporal domain or history table) that are encoded with the same reordering method as that of the target video unit are inserted into the list. c. For example, if the target video unit is to be coded with sample reordering, only those motion candidates (from the spatial domain or the temporal domain or the history table) that are coded with sample reordering are inserted into the list. d. For example, if the target video unit is not coded using sample reordering, those motion candidates (from the spatial domain or temporal domain or the history table) coded using the same reordering method may not be inserted into the list. e. Alternatively, the generation of a motion list for a video unit may not depend on the reordering method associated with each motion candidate. f. For example, adaptive reordering of merge candidates (ARMC) of video units may depend on the reordering method. a. For example, if the target video unit is to be encoded using sample reordering, motion candidates encoded using the same reordering method as that of the target video unit may be placed before those motion candidates encoded using a different reordering method. b. For example, if the target video unit is to be encoded with sample reordering, motion candidates encoded with sample reordering (but regardless of the type of sample reordering method) may be placed before those motion candidates encoded with a different reordering method. c. For example, if the target video unit is encoded without sample reordering, motion candidates that are encoded without the reordering method may be placed before those motion candidates that are encoded with the reordering method. d. Alternatively, ARMC may be applied to video units regardless of the reordering method associated with each motion candidate. 2. Regarding the implicit determination of sample reordering (eg, the second problem and related problems), the following method is proposed. a. Whether to reorder the reconstructed / original / predicted samples of a video unit can be implicitly derived from the codec information at both the encoder and the decoder. a. Implicit derivation can be based on cost / error / difference calculated using codec information. i. For example, the cost / error / difference can be calculated based on template matching. ii. For example, template matching can be performed by comparing samples in the first template and the second template. 1. For example, a first template is constructed from a set of predefined samples that are neighbors to the current video unit, and a second template is constructed from a set of corresponding samples that are neighbors to the reference video unit. 2. For example, the cost / error may refer to the cumulative sum of the differences between the samples in the first template and the corresponding samples in the second template. a. For example, the difference may be based on the luma sample values. 3. For example, a sample may refer to a reconstructed sample or a variant based on a reconstructed sample. 4. For example, a sample can refer to a predicted sample or a variant based on a predicted sample. b. For example, the first cost (represented by Cost0) can be calculated without reordering, and the second cost (represented by Cost1) can be calculated by using the ordering. Finally, the minimum cost value among {Cost0, Cost1} is identified, and the corresponding codec method (without reordering or with reordering) is determined as the final codec method of the video unit. c. Alternatively, whether to reorder the reconstructed / original / predicted samples of a video unit may be signaled in the bitstream. i. For example, it can be signaled by a syntax element (eg, a flag). b. Which reordering method is used to reorder the reconstructed / original / prediction samples can be implicitly derived from the codec information at both the encoder and the decoder. a. For example, whether to flip horizontally or vertically. b. Implicit derivation can be based on cost / error / difference calculated using codec information. i. For example, the cost / error / difference can be calculated based on template matching. ii. For example, template matching can be performed by comparing samples in the first and second templates. 1. For example, a first template is constructed from a set of predefined samples that are neighbors to the current video unit, and a second template is constructed from a set of corresponding samples that are neighbors to the reference video unit. 2. For example, the cost / error may refer to the cumulative sum of the differences between the samples in the first template and the corresponding samples in the second template. a. For example, the difference may be based on the luma sample values. 3. For example, a sample may refer to a reconstructed sample or a variant based on a reconstructed sample. 4. For example, a sample can refer to a predicted sample or a variant based on a predicted sample. iii. For example, the first cost (denoted by Cost0) may be calculated without using reordering method A. The second cost (represented by Cost1) can be calculated using reordering method B. Finally, The minimum cost value among {Cost0, Cost1} is identified, and the corresponding codec method (reordering method A, reordering method B) is determined as the final codec method of the video unit. c. Alternatively, which reordering method is used to reorder the reconstructed / original / predicted samples of a video unit can be signaled in the bitstream. i. For example, it may be signaled by a syntax element (eg, a flag, an index, a parameter or a variable). c. Whether or which reordering method to use to reorder the reconstructed / original / prediction samples of a video unit can be implicitly derived from the codec information at both the encoder and the decoder. a. For example, the first cost (represented by Cost0) can be calculated without reordering, the second cost (represented by Cost1) can be calculated using reordering method A; the third cost (represented by Cost2) can be calculated using reordering method B. Finally, the minimum cost value among {Cost0, Cost1, Cost2} is identified, and the corresponding codec method (without reordering, reordering method A, reordering method B) is determined as the final codec method of the video unit. 3. Regarding how to reorder samples (eg, the third problem and related problems), the following method is proposed. b. A possible sample reordering method can refer to one or more of the following processes: a. The reordering process can be applied on a video unit basis. i. For example, the reordering process can be based on block / CU / PU / TU. ii. For example, the reordering process may not be tile / slice / picture based. b. Samples of a video unit may be transformed according to an M-parameter model (eg, M=2, 4, 6, or 8). c. Samples of a video unit can be reordered. d. Samples of video units can be rotated. e. The samples of the video unit can be transformed according to the affine model. f. The samples of the video unit can be transformed according to the linear model. g. The samples of the video unit can be transformed according to the projection model. h. The samples of the video unit can be flipped in the horizontal direction. i. The samples of the video unit can be flipped along the vertical direction. General Aspects 4. Whether and / or how to apply the above-disclosed method may be signaled at the sequence level / picture group level / picture level / slice level / tile group level, for example in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / PPS / slice header / tile group header. 5. Whether and / or how to apply the above disclosed methods can be signaled in PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / tile / sub-picture / other kinds of regions containing more than one sample or pixel. 6. Whether and / or how to apply the above disclosed method may depend on codec information, such as block size, color format, single / dual tree partitioning, color component, slice / picture type. 3 Questions How to handle the interaction between RRIBC and template matching based IBC (eg, IBC-TM) needs to be considered. 1. In ECM-5.0, IBC-TM-MERGE mode is included, and RRIBC does not exist in the ECM code, so how to construct the IBC-TM- The IBC-TM-MERGE list for MERGE mode is unknown. 2. In ECM-5.0, due to the use of IBC-TM for IBC-AMVP mode, TM is mandatory for refining each IBC-AMVP candidate, and RRIBC does not exist in the ECM code. Therefore, it is undefined how to construct the RRIBC-based IBC-AMVP list when IBC-TM is allowed. How to handle the interaction between RRIBC and IBC with merge-based motion vector difference (e.g., IBC_MBVD) needs to be considered. 1. If IBC_MBVD is allowed / used for screen content codec, how to interact with RRIBC, such as whether to derive IBC_MBVD motion and / or flip type from neighboring blocks of RRIBC codec can be defined. 2. If IBC_MBVD is allowed / used for screen content codec, how to interact with RRIBC, such as the design of MBVD offset regarding RRIBC flip type can be defined. 4 Detailed solutions The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow sense. In addition, these solutions can be combined in any way. The term “video unit” or “codec unit” may refer to a picture, a slice, a tile, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. The term "block" may refer to a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, a TB. Note that the terms mentioned below are not limited to the specific terms defined in existing standards. Any changes in codec tools are also applicable. 4.1 Regarding the interaction between RRIBC and IBC-TM, such as how to derive motion data and flip type for IBC-TM-MERGE codec blocks (eg, Problem 1 and related issues), the following approach is proposed. a. For example, an IBC-TM-MERGE candidate may inherit motion from neighboring blocks that were decoded by RRIBC. a. In one example, motion can be inherited directly. b. In one example, motion may first be adjusted (eg, have a motion offset added to it) and then inherited. c. Alternatively, an IBC-TM-MERGE candidate may not inherit motion from neighboring blocks decoded by RRIBC. b. For example, an IBC-TM-MERGE candidate may not inherit the flip type from a neighboring block that is decoded by RRIBC. a. In one example, the flip type of an IBC-TM-MERGE candidate may always be set equal to NO_FLIP, regardless of whether the motion of this IBC-TM merge candidate is inherited from a neighboring block that is decoded by RRIBC. c. Alternatively, the IBC-TM-MERGE candidate may inherit the flip type from a neighboring block that is decoded by RRIBC. a. In one example, the rollover type of this IBC-TM-MERGE candidate is set equal to the rollover type of the neighboring block decoded by RRIBC. d. For example, an IBC-TM-MERGE candidate may inherit motion from a neighboring block decoded with RRIBC, but never inherit flip type from a neighboring block decoded with RRIBC. a. In one example, motion can be inherited directly. b. In one example, motion may first be adjusted (eg, have a motion offset added to it) and then inherited. c. In one example, the flip type of an IBC-TM-MERGE candidate may always be set equal to NO_FLIP. e. For example, IBC-TM-MERGE candidates may be prohibited from being derived based on neighboring blocks that are decoded by RRIBC. a. In this case, the motion and flip types of neighboring blocks decoded by RRIBC may be prohibited from being added to the IBC-TM-MERGE candidate. b. In this case, if the neighboring block is coded with RRIBC, the codec information of the neighboring block is never inserted into the IBC-TM-MERGE list. f. For example, an IBC-TM-MERGE candidate / block may be RRIBC coded. a. In one example, the motion data (motion vector, reference index and / or flip type) of an RRIBC-coded IBC-TM-MERGE block may be inherited from an RRIBC-coded neighboring block. b. For example, additionally, motion vectors inherited from neighboring blocks may be adjusted through a motion adjustment process. i. For example, additionally, the adjusted motion vector may be further refined by a template matching based method. c. For example, additionally, the motion vectors inherited from neighboring blocks can be further refined by a template matching based method. i. For example, additionally, the refined motion vectors may be further adjusted through a motion adjustment process. d. For example, the motion adjustment process can be based on the flip type and / or the position / location / coordinates of the current block and neighboring blocks. i. For example, motion adjustment can be along one direction (horizontal or vertical). ii. For example, horizontal adjustment can be applied to horizontal flipping. iii. For example, vertical adjustment can be applied to vertical flip. e. For example, the motion refinement (eg, TM-based) offset of an IBC-TM-MERGE block / candidate for RRIBC codec may depend on the flip type. i. In one example, for horizontally flipped RRIBC codec IBC-TM- MERGE blocks / candidates only horizontal motion vector offsets are allowed (e.g. FLIP_TYPE=FLIP_HOR). 1. Furthermore, alternatively, in case an IBC-TM-MERGE block is encoded with horizontally flipped RRIBC, the vertical component of the motion vector offset may be required to be equal to 0. ii. In one example, for a vertically flipped RRIBC codec IBC-TM- MERGE blocks / candidates only vertical motion vector offsets are allowed (e.g. FLIP_TYPE=FLIP_VER). 1. Furthermore, alternatively, in case an IBC-TM-MERGE block / candidate is coded with vertically flipped RRIBC, the horizontal component of the motion vector offset may be required to be equal to 0. 4.2. When IBC-TM is allowed (eg, Question 2 and related issues), the following method is proposed regarding the interaction between RRIBC and IBC-TM such as how to construct an IBC AMVP list based on RRIBC. a. For example, in the case where the current video unit is in IBC-AMVP mode with RRIBC (eg, the flip type of the current video unit is not equal to NO_FLIP), the AMVP candidate may not be allowed to be refined by template matching (eg, IBC-TM-AMVP). b. For example, in the case where the current video unit is in IBC-AMVP mode without RRIBC (eg, the flip type of the current video unit is equal to NO_FLIP), the AMVP candidates may be allowed to be refined by template matching (eg, IBC-TM-AMVP). c. For example, during the IBC-AMVP list generation process, the MVD threshold used for similarity checking (e.g., pruning process by comparing the similarity between a potential candidate and another candidate already in the list) may be different in different video units depending on whether the current video unit is encoded and decoded by RRIBC or non-RRIBC. a. In one example, assuming that the MVD threshold of the video unit of the IBC-AMVP non-RRIBC codec is equal to K1, and the MVD threshold of the IBC-AMVP RRIBC video unit is equal to K2, then K1 may not be equal to K2. b. Additionally, furthermore, K1 may be greater than K2. c. Additionally, furthermore, K1 and / or K2 may be predefined. i. For example, K1 and / or K2 may be equal to a specific number (eg, 0 or 1). ii. For example, K1 and / or K2 may depend on the dimensions of the current video unit (eg, width / height, number of samples / pixels). iii. For example, K1 and / or K2 may be derived based on the same rules used in the similarity check of existing codec tools in the codec (e.g., IBC-TM-MERGE mode, inter-frame TM mode, etc.). d. Alternatively, K1 may be equal to K2. d. For example, when the current video unit is in IBC-AMVP mode with RRIBC (eg, the flip type of the current video unit is not equal to NO_FLIP) and the MVP candidate of the current video unit is also coded and decoded by RRIBC. a. In one example, first the motion vector of the MVP candidate may be adjusted and then used for the current video unit. b. In one example, motion adjustment may be performed only if the flip type of the current video unit and the flip type of the neighboring block used to derive the MVP candidate are the same. i. Alternatively, motion adjustment can be performed as long as the current video unit and neighboring blocks are coded by RRIBC. c. In one example, motion adjustment may refer to adding motion offset to the MVP candidate. d. In one example, the motion offset may depend on the block size and / or position of the current video unit. e. In one example, the motion offset may depend on the block size and / or position of the neighboring blocks used to derive the MVP candidate. e. For example, when the current video unit is in IBC-AMVP mode with non-RRIBC (eg, the flip type of the current video unit is equal to NO_FLIP) and the MVP candidate of the current video unit is RRIBC coded. a. In one example, the motion vector of the MVP candidate may not be adjusted. b. Alternatively, the motion vector of the MVP candidate may be adjusted (eg, by a motion adjustment process). i. In one example, motion adjustment can be used as long as the neighboring blocks are coded by RRIBC. ii. For example, additionally, the adjusted motion vector may be further refined by a template matching based method. c. In one example, motion adjustment may refer to adding motion offset to the MVP candidate. d. In one example, the motion offset may depend on the block size and / or position of the current video unit. e. In one example, the motion offset may depend on the block size and / or position of the neighboring blocks used to derive the MVP candidate. f. In one example, additionally, the motion vector candidates inherited from neighboring blocks can be further refined by a template matching based method. i. For example, additionally, the refined motion vectors may be further adjusted through a motion adjustment process. g. In one example, the motion adjustment process can be based on the flip type and / or the position / location / coordinates of the current block and neighboring blocks. i. For example, motion adjustment can be along one direction (horizontal or vertical). ii. For example, horizontal adjustment can be applied to horizontal flipping. iii. For example, vertical adjustment can be applied to vertical flip. h. In one example, the motion refinement (eg, TM-based) offset of the IBC-TM-AMVP block / candidate for RRIBC codec may depend on the flip type. i. In one example, only horizontal motion vector offsets are allowed for IBC-TM-AMVP blocks / candidates for horizontally flipped RRIBC codecs (eg, FLIP_TYPE= FLIP_HOR). 1. Furthermore, alternatively, in case the IBC-TM-AMVP block / candidate is coded with horizontally flipped RRIBC, the vertical component of the motion vector offset may be required to be equal to 0. ii. In one example, for a vertically flipped RRIBC-encoded IBC-TM- For AMVP blocks / candidates only vertical motion vector offsets are allowed (eg, FLIP_TYPE= FLIP_VER). 1. Furthermore, alternatively, in case the IBC-TM-MERGE block / candidate is coded with vertical flip AMVP, the horizontal component of the motion vector offset may be required to be equal to 0. 4.3 Regarding the interaction between RRIBC and IBC_MBVD, such as whether to derive the IBC_MBVD motion and / or flip type from the RRIBC codec neighbor blocks for the IBC_MBVD codec block (eg, question 3 and related questions), the following approach is proposed. a. For example, a block encoded with IBC_MBVD can derive motion from a neighboring block encoded with RRIBC. a. In one example, the motion of neighboring blocks of the RRIBC codec can be directly inherited for Base motion for the IBC_MBVD block. b. In one example, the motion of the neighboring blocks of the RRIBC codec may first be adjusted through a motion adjustment process (eg, adding a motion displacement to the motion based on the flip type), and then the adjusted motion may be used as the base motion for the IBC_MBVD block. c. In one example, the motion of the neighboring blocks of the RRIBC codec can be directly inherited as the base motion for the IBC_MBVD block, and the final block vector after adding the block vector difference can be adjusted through a motion adjustment process (e.g., adding motion displacement to the final block vector based on the flip type). b. In one example, the motion adjustment process can be based on the flip type and / or the position of the current block and the neighboring blocks / Location / Coordinates. a. For example, motion adjustment can be along one direction (horizontal or vertical). b. For example, horizontal adjustment can be applied to horizontal flipping. c. For example, vertical adjustment can be applied to vertical flip. c. For example, IBC_MBVD coded blocks may not derive motion from RRIBC coded neighboring blocks. a. In one example, the motion of neighboring blocks of the RRIBC codec may not be used as Base motion for the IBC_MBVD block. b. For example, IBC_MBVD codec blocks may be prohibited from being derived from neighboring blocks based on RRIBC codec. i. In this case, the motion and flip types of neighboring blocks of the RRIBC codec can be disabled from being inherited for the IBC_MBVD codec block. ii. In this case, if the neighbor block is coded using RRIBC, do not insert the codec information of the neighbor block into the IBC_MBVD-MERGE list. d. For example, an IBC_MBVD codec block can inherit the flip type from a neighboring block of the RRIBC codec. a. In one example, the rollover type of this IBC_MBVD candidate is set equal to Neighbor block flipping type for RRIBC codec. e. For example, an IBC_MBVD codec block may not inherit the flip type from a neighboring block of the RRIBC codec. a. In one example, the flip type of an IBC_MBVD candidate may always be set equal to NO_FLIP, regardless of whether the underlying motion of such an IBC_MBVD candidate is inherited from a neighboring block encoded by RRIBC. f. For example, the IBC_MBVD codec block can derive both motion and flip type from the RRIBC coded neighboring blocks. a. Alternatively, an IBC_MBVD-coded block may derive motion (but not flip type) from an RRIBC-coded neighboring block. b. Alternatively, an IBC_MBVD-coded block may inherit the flip type (but not the motion) from a neighboring RRIBC-coded block. 4.4 Regarding the interaction between RRIBC and IBC_MBVD, such as how to design the MBVD offset of blocks for IBC_MBVD encoding and decoding (eg, Question 4 and related issues), the following method is proposed. a. For example, an MBVD offset may be added to a base motion candidate, and the allowable MBVD offset associated with an RRIBC codec block (or base motion candidate) may be different from the allowable MBVD offset associated with a non-RRIBC codec block (or base motion candidate). a) In one example, the allowable MBVD offsets for RRIBC codec blocks may be a subset of those for non-RRIBC codec blocks. b) In one example, the allowable MBVD offsets associated with the RRIBC codec base motion candidates may be a subset of those MBVD offsets associated with the non-RIBC codec base motion candidates. c) Alternatively, the allowable MBVD offsets associated with the RRIBC codec base motion candidates may be the same as those associated with the non-RRIBC codec base motion candidates. b. For example, which MBVD offsets are allowed for a codec block (or base motion candidate) may depend on the RRIBC flip type of such block (or base motion candidate). a) In one example, only horizontal MBVD offsets are allowed for horizontally flipped RRIBC codec blocks (eg, FLIP_TYPE=FLIP_HOR). i. Furthermore, alternatively, in the case where the block is encoded and decoded using horizontal flip RRIBC, The vertical component of the MBVD offset may be required to be equal to zero. b) In one example, additionally, for vertically flipped RRIBC codec blocks only vertically MBVD offset is allowed (eg, FLIP_TYPE=FLIP_VER). i. Furthermore, alternatively, in the case where the block is coded using vertical flip RRIBC, The horizontal component of the MBVD offset may be required to be equal to zero. c) In one example, only horizontal MBVD offsets are allowed for horizontally flipped RRIBC base motion candidates (eg, FLIP_TYPE=FLIP_HOR). i. Furthermore, alternatively, in case the base motion candidate is coded with horizontally flipped RRIBC, the vertical component of the MBVD offset may be required to be equal to 0. d) In one example, additionally, only vertical MBVD offsets are allowed for vertically flipped RRIBC base motion candidates (eg, FLIP_TYPE=FLIP_VER). i. Furthermore, alternatively, in case the base motion candidate is coded with vertical flip RRIBC, the horizontal component of the MBVD offset may be required to be equal to 0. c. For example, the final IBC_MBVD motion vector candidates based on RRIBC and the final IBC_MBVD motion vector candidates based on non-RRIBC may be grouped together. a) Furthermore, alternatively, the MMVD candidate index may be encoded and decoded based on the group. b) Furthermore, alternatively, a decoder-side re-ordering (such as sorting) process may be applied to order all candidates in a group based on cost (such as template cost). d. For example, the final IBC_MBVD motion vector candidates based on RRIBC may be grouped together as a first subgroup, and the final IBC_MBVD motion vector candidates based on non-RRIBC may be grouped together as a second subgroup. a) Furthermore, alternatively, the MMVD candidate index may be encoded and decoded based on a designated subgroup. b) Furthermore, alternatively, a decoder-side re-ordering (such as sorting) process may be applied to sort the candidates in each sub-group separately based on cost (such as template cost). e. In one example, "RRIBC codec" means that flip type is not equal to NO_FLIP. f. In one example, "non-RRIBC codec" means flip type equals NO_FLIP. General Aspects 4.5 In the above examples, a video unit may refer to a color component / sub-picture / slice / tile / codec tree unit (CTU) / CTU row / CTU group / codec unit (CU) / prediction unit (PU) / transform unit (TU) / codec tree block (CTB) / codec 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 or pixel. 4.6 Whether and / or how to apply the above-disclosed method can be signaled at the sequence level / picture group level / picture level / slice level / tile group level, for example in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / tile group header.

[0080] More details of embodiments of the present disclosure related to the interaction of RRIBC and IBC template matching will be described below. The embodiments of the present disclosure should be considered as examples to explain general concepts and should not be interpreted in a narrow sense. In addition, these embodiments can be applied individually or in combination in any way.

[0081] As used herein, the term "block" may refer to a color component, a sub-picture, a slice, a tile, a coding tree unit (CTU), a CTU row, a CTU group, a codec unit (CU), a prediction unit (PU), a transform unit (TU), a codec tree block (CTB), a codec block (CB), a prediction block (PB), a transform block (TB), a sub-block of a video block, a sub-region within a video block, a video processing unit containing multiple samples / pixels, etc. A block may be rectangular or non-rectangular.

[0082] Fig.121 shows a flow chart of a method 1200 for video processing according to some embodiments of the present disclosure. The method 1200 may be implemented during conversion between a current block of a video and a bitstream of the video. Fig.12 As shown, method 1200 starts at 1202, where motion information of a current block is determined based on motion information of neighboring blocks of the current block and an IBC-MBVD mode. The neighboring blocks are encoded and decoded using a reconstruction reordered intra-block copy (RRIBC) mode. As an example and not a limitation, the motion information may include a motion vector, a reference index, a reference list, etc. In some embodiments, the motion information of the neighboring blocks may be used as a base motion candidate for the IBC-MBVD mode to generate motion information of the current block.

[0083] In some embodiments, in RRIBC mode, adjustments may be applied to reconstructed samples of neighboring blocks. As an example and not limitation, adjustments may include reordering reconstructed samples, flipping reconstructed samples, moving reconstructed samples, rotating reconstructed samples, transforming reconstructed samples, etc. It should be understood that the above examples are described for illustrative purposes only. The scope of the present disclosure is not limited in this regard.

[0084] At 1204, conversion is performed based on the motion information of the current block. In one example, the conversion may include encoding the current block into a bitstream. Alternatively or additionally, the conversion may include decoding the current block from the bitstream.

[0085] Based on the above, the motion information of the current block is determined based on the motion information of the neighboring blocks encoded and decoded by RRIBC and the IBC-MBVD mode. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-MBVD mode, thereby advantageously improving the encoding and decoding efficiency and encoding and decoding quality.

[0086] In some embodiments, at 1202, motion information of neighboring blocks may be adjusted based on a motion adjustment process. As an example and not limitation, a motion displacement may be added to the motion information of the current block during the motion adjustment process. In addition, based on the adjusted motion information and the IBC-MBVD mode, motion information of the current block may be generated. The adjusted motion information may be used as a base motion candidate for the IBC-MBVD mode to generate motion information of the current block.

[0087] In some alternative embodiments, at 1202, based on the motion information of the neighboring blocks and the IBC-MBVD mode, intermediate motion information may be determined. The motion information of the neighboring blocks may be used as a base motion candidate for the IBC-MBVD mode to generate the intermediate motion information. In addition, the motion information of the current block may be generated by adjusting the intermediate motion information based on a motion adjustment process. As an example and not limitation, a motion shift may be added to the intermediate motion information during the motion adjustment process.

[0088] In some embodiments, the motion adjustment process may depend on the flipping type of the current block, the flipping type of the neighboring blocks, the position of the current block, the position of the neighboring blocks, the coordinates of the current block, or the coordinates of the neighboring blocks, etc.

[0089] In some embodiments, the adjustment may be performed along a single direction during the motion adjustment process. For example, if the flip type of the neighboring block is horizontal flipping, the single direction may be a horizontal direction. Alternatively or additionally, if the flip type of the neighboring block is vertical flipping, the single direction may be a vertical direction.

[0090] In some embodiments, the flip type of the current block can be determined independently of the flip type of the neighboring block. That is, the flip type of the neighboring block will not be considered for determining the flip type of the current block. In this case, the current block can derive motion information (but not the flip type) from the RRIBC codec neighboring block. For example, the flip type of the current block can always be set to be equal to no flip. In some alternative embodiments, the flip type of the current block can be determined based on the flip type of the neighboring block. In this case, the current block can derive both motion information and flip type from the RRIBC codec neighboring block. For example, the flip type of the current block can be set to be equal to the flip type of the neighboring block.

[0091] In some embodiments, the video may further include another block different from the current block. The other neighboring block is encoded and decoded using the RRIBC mode. The motion information of the other block can be determined based on the IBC-MBVD mode independently of the motion information of the other neighboring block of the other block. That is, the motion information of the other neighboring block will not be considered for generating the motion information of the other block.

[0092] In some embodiments, the motion information of another block may not be allowed to be used as a base motion candidate for the IBC-MBVD mode. Alternatively or additionally, the other block may not be allowed to be determined based on another neighboring block. In some other embodiments, the motion information of another neighboring block and the flip type of the other neighboring block may not be allowed to be added to the motion candidate list for the other block. Alternatively or additionally, the codec information of another neighboring block may not be allowed to be added to the motion candidate list for the other block.

[0093] In some alternative embodiments, the flip type of the other block may be determined based on the flip type of the other neighboring block. In this case, the other block may derive the flip type (but not the motion information) from the other neighboring block encoded by RRIBC. For example, the flip type of the other block may be set equal to the flip type of the other neighboring block.

[0094] In some embodiments, if the current block is encoded using the RRIBC mode, a first set of MBVD offsets may be allowed to be added to the base motion candidate for the IBC-MBVD mode. If the current block is not encoded using the RRIBC mode, a second set of MBVD offsets may be allowed to be added to the base motion candidate. In some alternative or additional embodiments, if the base motion candidate for the IBC-MBVD mode is encoded using the RRIBC mode, a first set of MBVD offsets may be allowed to be added to the base motion candidate. If the base motion candidate is not encoded using the RRIBC mode, a second set of MBVD offsets may be allowed to be added to the base motion candidate.

[0095] In some embodiments, the first set of MBVD offsets may be the same as the second set of MBVD offsets. In some alternative embodiments, the first set of MBVD offsets may be different from the second set of MBVD offsets. By way of example and not limitation, the first set of MBVD offsets may be a subset of the second set of MBVD offsets. Alternatively, the second set of MBVD offsets may be a subset of the first set of MBVD offsets.

[0096] In some embodiments, a set of MBVD offsets allowed to be added to a base motion candidate for an IBC-MBVD mode may depend on the flip type of the current block or the flip type of the base motion candidate. In one example, if the flip type of the current block is horizontal flip, a set of MBVD offsets may include a set of horizontal MBVD offsets. Additionally, the vertical component of each MBVD offset in a set of MBVD offsets may be equal to zero. If the flip type of the current block is vertical flip, a set of MBVD offsets may include a set of vertical MBVD offsets. Additionally, the horizontal component of each MBVD offset in a set of MBVD offsets may be equal to zero.

[0097] Additionally or alternatively, if the flip type of the base motion candidate is horizontal flip, then the set of MBVD offsets may include a set of horizontal MBVD offsets. For example, the vertical component of each MBVD offset in the set of MBVD offsets may be equal to zero. If the flip type of the base motion candidate may be vertical flip, then the set of MBVD offsets may include a set of vertical MBVD offsets. For example, the horizontal component of each MBVD offset in the set of MBVD offsets may be equal to zero.

[0098] In some embodiments, the motion candidates for RRIBC encoding and decoding of IBC-MBVD mode and the motion candidates for non-RIBC encoding and decoding of IBC-MBVD mode can be grouped into a single group of motion candidates. Additionally, the index of the motion candidates for IBC-MBVD mode can be encoded and decoded based on the single group of motion candidates. In addition, the motion candidates in the single group of motion candidates can be sorted based on the cost of the motion candidates (such as template cost).

[0099] In some alternative embodiments, the motion candidates for RRIBC encoding and decoding of the IBC-MBVD mode can be grouped into a first group of motion candidates, and the motion candidates for non-RRIBC encoding and decoding of the IBC-MBVD mode can be grouped into a second group of motion candidates. Additionally, based on the first group of motion candidates or the second group of motion candidates, the index of the motion candidates for the IBC-MBVD mode can be encoded and decoded. In addition, based on the template cost of the motion candidates, the motion candidates in the first group of motion candidates or the second group of motion candidates can be sorted.

[0100] As used herein, if a block is coded using RRIBC, then the flip type of the block is not equal to no flip, and the block may also be referred to as an RRIBC coded block. If the current block is not coded using RRIBC, then the flip type of the current block is equal to no flip, and the block may also be referred to as a non-RRIBC coded block.

[0101] In some embodiments, whether and / or how to apply the method may be indicated at a sequence level, a group of picture level, a picture level, a slice level, a tile group level, etc. In some embodiments, whether and / or how to apply the method may be indicated in a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, a tile group header, etc.

[0102] According to another embodiment of the present disclosure, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a device for video processing. In the method, based on motion information of neighboring blocks of a current block of the video and an IBC-MBVD mode, motion information of the current block is determined. Neighboring blocks are encoded and decoded using an RRIBC mode. In addition, a bitstream is generated based on the motion information of the current block.

[0103] According to some other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. In the method, based on the motion information of the neighboring blocks of the current block of the video and the IBC-MBVD mode, the motion information of the current block is determined. The neighboring blocks are encoded and decoded using the RRIBC mode. In addition, a bitstream is generated based on the motion information of the current block, and the bitstream is stored in a non-transitory computer-readable recording medium.

[0104] Fig.13 1 is a flow chart showing another method 1300 for video processing according to some embodiments of the present disclosure. The method 1300 may be implemented during conversion between a current block of a video and a bitstream of the video. Fig.13 As shown, method 1300 starts at 1302, where the motion information of the current block is determined based on the motion information of the neighboring blocks of the current block and the IBC-TM-MERGE mode. Both the current block and the neighboring blocks are encoded and decoded using the RRIBC mode. As an example and not a limitation, the motion information may include motion vectors, reference indexes, reference lists, etc. In some embodiments, the motion information of the current block may be the same as the motion information of the neighboring blocks. Additionally or alternatively, the flip type of the current block may be the same as the flip type of the neighboring blocks. In other words, the motion information and / or flip type of the current block may be inherited directly from the neighboring blocks encoded and decoded by RRIBC.

[0105] In some embodiments, in RRIBC mode, adjustments may be applied to reconstructed samples of neighboring blocks or the current block. As an example and not limitation, adjustments may include reordering reconstructed samples, flipping reconstructed samples, moving reconstructed samples, rotating reconstructed samples, transforming reconstructed samples, etc. It should be understood that the above examples are described for illustrative purposes only. The scope of the present disclosure is not limited in this regard.

[0106] At 1304, a conversion is performed based on the motion information of the current block. In one example, the conversion may include encoding the current block into a bitstream. Alternatively or additionally, the conversion may include decoding the current block from the bitstream.

[0107] In view of the above situation, based on the motion information of the neighboring blocks of RRIBC coding and the IBC-TM-MERGE mode, the motion information of the current block of RRIBC coding is determined. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-TM-MERGE mode, thereby advantageously improving the coding efficiency and coding quality.

[0108] In some embodiments, at 1302, motion information of a current block may be generated by adjusting motion information of neighboring blocks based on a motion adjustment process. As an example and not limitation, a motion displacement may be added to the motion information during the motion adjustment process.

[0109] Alternatively, at 1302, intermediate motion information may be obtained by adjusting motion information of neighboring blocks based on a motion adjustment process. As an example and not limitation, motion displacement may be added to the motion information during the motion adjustment process. In addition, motion information of the current block may be generated by refining the intermediate motion information through a motion refinement process based on template matching.

[0110] In some alternative embodiments, at 1302, intermediate motion information may be obtained by refining motion information of neighboring blocks according to a motion refinement process based on template matching. In addition, motion information of the current block may be generated by adjusting the intermediate motion information based on a motion adjustment process. As an example and not limitation, motion displacement may be added to the intermediate motion information during the motion adjustment process.

[0111] In some further embodiments, at 1302 , motion information of the current block may be generated by refining motion information of neighboring blocks according to a template matching based motion refinement process.

[0112] In some embodiments, the motion adjustment process may depend on the flipping type of the current block, the flipping type of the neighboring blocks, the position of the current block, the position of the neighboring blocks, the coordinates of the current block or the coordinates of the neighboring blocks, etc.

[0113] In some embodiments, the adjustment may be performed along a single direction during the motion adjustment process. For example, if the flip type of the neighboring block is horizontal flipping, the single direction may be the horizontal direction. If the flip type of the neighboring block is vertical flipping, the single direction may be the vertical direction.

[0114] In some embodiments, a set of motion vector (MV) offsets allowed to be used in the template matching based motion refinement process may depend on the flip type of the current block or the flip type of the motion candidate for the IBC-TM-MERGE mode. In the template matching based motion refinement process, a set of MV offsets may be used to refine the motion information (such as motion vectors) of the current block or the IBC-TM-MERGE candidate of the current block.

[0115] In some embodiments, if the flip type of the current block is horizontal flip, the set of MV offsets may include a set of horizontal MV offsets. For example, the vertical component of each MV offset in the set of MV offsets may be equal to zero. If the flip type of the motion candidate is horizontal flip, the set of MV offsets may include a set of horizontal MV offsets. For example, the vertical component of each MV offset in the set of MV offsets may be equal to zero.

[0116] Additionally or alternatively, if the flip type of the current block is vertical flip, the set of MV offsets may include a set of vertical MV offsets. For example, a horizontal component of each MV offset in the set of MV offsets may be equal to zero. If the flip type of the motion candidate is vertical flip, the set of MV offsets may include a set of vertical MV offsets. For example, a horizontal component of each MV offset in the set of MV offsets may be equal to zero.

[0117] In some embodiments, whether and / or how to apply the method may be indicated at a sequence level, a picture group level, a picture level, a slice level, a tile group level, etc. In some embodiments, whether and / or how to apply the method may be indicated in a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, a tile group header, etc.

[0118] According to another embodiment of the present disclosure, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a device for video processing. In the method, based on the motion information of neighboring blocks of the current block of the video and the IBC-TM-MERGE mode, the motion information of the current block is determined. The current block and the neighboring blocks are encoded and decoded using the RRIBC mode. In addition, the bitstream is generated based on the motion information of the current block.

[0119] According to some other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. In the method, based on the motion information of the neighboring blocks of the current block of the video and the IBC-TM-MERGE mode, the motion information of the current block is determined. The current block and the neighboring blocks are encoded and decoded using the RRIBC mode. In addition, the bitstream is generated based on the motion information of the current block and is also stored in a non-transitory computer-readable recording medium.

[0120] Fig.14 1400 is a flowchart of another method 1400 for video processing according to some embodiments of the present disclosure. The method 1400 may be implemented during the conversion between the current block of the video and the bitstream of the video. Fig.14 As shown, method 1400 begins at 1402, where a motion candidate for a current block is determined based on motion information of neighboring blocks of the current block and the IBC-AMVP mode. The neighboring blocks are encoded and decoded using the RRIBC mode. In some embodiments, the current block can be encoded and decoded using the RRIBC mode. Alternatively, the current block may not be encoded and decoded using the RRIBC mode.

[0121] In some embodiments, in RRIBC mode, adjustments may be applied to reconstructed samples of neighboring blocks. As an example and not limitation, adjustments may include reordering reconstructed samples, flipping reconstructed samples, moving reconstructed samples, rotating reconstructed samples, or transforming reconstructed samples, etc. It should be understood that the above examples are described for illustrative purposes only. The scope of the present disclosure is not limited in this regard.

[0122] At 1404, based on the motion candidate, motion information of the current block is determined. In some embodiments, the motion information of the current block can be generated by adjusting the motion vector of the motion candidate based on a motion adjustment process. As an example and not limitation, a motion displacement can be added to the motion vector during the motion adjustment process.

[0123] Alternatively, the intermediate motion vector may be obtained by adjusting the motion vector of the motion candidate based on the motion adjustment process. As an example and not limitation, the motion displacement may be added to the motion vector in the motion adjustment process. In addition, the motion information of the current block may be generated by refining the intermediate motion vector according to the motion refinement process based on template matching.

[0124] In some alternative embodiments, the intermediate motion vector may be obtained by refining the motion vector of the motion candidate according to a motion refinement process based on template matching. In addition, the motion information of the current block may be generated by adjusting the intermediate motion vector based on a motion adjustment process. As an example and not limitation, the motion displacement may be added to the intermediate motion vector in the motion adjustment process.

[0125] In some other embodiments, the motion information of the current block may be obtained by refining the motion vector of the motion candidate through a motion refinement process based on template matching. It should be understood that the above examples are described for illustrative purposes only. The scope of the present disclosure is not limited in this regard.

[0126] At 1406, conversion is performed based on the motion information of the current block. In one example, the conversion may include encoding the current block into a bitstream. Alternatively or additionally, the conversion may include decoding the current block from the bitstream.

[0127] Based on the above, the motion information of the current block is determined based on the motion information of the neighboring blocks encoded by RRIBC and the IBC-AMVP mode. Compared with the traditional scheme, the proposed method can better support the interaction between the RRIBC mode and the IBC-AMVP mode, thereby advantageously improving the encoding and decoding efficiency and encoding and decoding quality.

[0128] In some embodiments, the motion adjustment process may depend on the flipping type of the current block, the flipping type of the neighboring blocks, the position of the current block, the position of the neighboring blocks, the coordinates of the current block, or the coordinates of the neighboring blocks, etc.

[0129] In some embodiments, the adjustment may be performed along a single direction during the motion adjustment process. For example, if the flip type of the neighboring block is horizontal flipping, the single direction may be the horizontal direction. If the flip type of the neighboring block is vertical flipping, the single direction may be the vertical direction.

[0130] In some embodiments, a set of motion vector (MV) offsets allowed to be used in the template matching based motion refinement process may depend on the flip type of the current block or the flip type of the motion candidate. In the template matching based motion refinement process, a set of MV offsets may be used to refine the motion information (such as motion vector) of the current block or the IBC-TM-AMVP candidate of the current block.

[0131] In some embodiments, if the flip type of the current block is horizontal flip, the set of MV offsets may include a set of horizontal MV offsets. For example, the vertical component of each MV offset in the set of MV offsets may be equal to zero. If the flip type of the motion candidate is horizontal flip, the set of MV offsets may include a set of horizontal MV offsets. For example, the vertical component of each MV offset in the set of MV offsets may be equal to zero.

[0132] Additionally or alternatively, if the flip type of the current block is vertical flip, the set of MV offsets may include a set of vertical MV offsets. For example, a horizontal component of each MV offset in the set of MV offsets may be equal to zero. If the flip type of the motion candidate is vertical flip, the set of MV offsets may include a set of vertical MV offsets. For example, a horizontal component of each MV offset in the set of MV offsets may be equal to zero.

[0133] In some embodiments, whether and / or how to apply the method may be indicated at a sequence level, a group of picture level, a picture level, a slice level, a tile group level, etc. In some embodiments, whether and / or how to apply the method may be indicated in a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, a tile group header, etc.

[0134] According to another embodiment of the present disclosure, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by a device for video processing. In the method, based on motion information of neighboring blocks of a current block of the video and an IBC-AMVP mode, a motion candidate of the current block is determined. The neighboring blocks are encoded and decoded using the RRIBC mode. The motion information of the current block is determined based on the motion candidate. In addition, a bitstream is generated based on the motion information of the current block.

[0135] According to some other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. In this method, based on the motion information of neighboring blocks of the current block of the video and the IBC-AMVP mode, a motion candidate of the current block is determined. The neighboring blocks are encoded and decoded using the RRIBC mode. The motion information of the current block is determined based on the motion candidate. In addition, the bitstream is generated based on the motion information of the current block, and the bitstream is also stored in a non-transitory computer-readable recording medium.

[0136] Embodiments of the present disclosure may be described according to the following clauses, features of which may be combined in any reasonable way.

[0137] Clause 1. A method for video processing, comprising: for conversion between a current block of a video and a bitstream of the video, determining motion information of the current block based on motion information of neighboring blocks of the current block and an intra-frame block copy merge mode with block vector difference (IBC-MBVD) mode, the neighboring blocks are encoded and decoded using a reconstruction reordered intra-frame block copy (RRIBC) mode; and performing conversion based on the motion information of the current block.

[0138] Clause 2. The method of clause 1, wherein motion information of neighboring blocks is used as base motion candidates for the IBC-MBVD mode.

[0139] Clause 3. A method according to Clause 1, wherein determining the motion information of the current block comprises: adjusting the motion information of the neighboring blocks based on a motion adjustment process; and generating the motion information of the current block based on the adjusted motion information and the IBC-MBVD mode, the adjusted motion information being used as a base motion candidate for the IBC-MBVD mode.

[0140] Clause 4. The method of clause 3, wherein during the motion adjustment process, the motion displacement is added to the motion information of the current block.

[0141] Clause 5. A method according to Clause 1, wherein determining the motion information of the current block comprises: determining intermediate motion information based on motion information of neighboring blocks and an IBC-MBVD mode, the motion information of the neighboring blocks being used as base motion candidates for the IBC-MBVD mode; and generating the motion information of the current block by adjusting the intermediate motion information based on a motion adjustment process.

[0142] Clause 6. The method of clause 5, wherein the motion displacement is added to the intermediate motion information during the motion adjustment process.

[0143] Clause 7. A method according to any one of clauses 3 to 6, wherein the motion adjustment process depends on at least one of the following: the flipping type of the current block, the flipping type of the neighboring block, the position of the current block, the position of the neighboring block, the coordinates of the current block, or the coordinates of the neighboring block.

[0144] Clause 8. The method of any one of clauses 3 to 7, wherein the adjustment is performed in a single direction during a motion adjustment.

[0145] Clause 9. The method of clause 8, wherein if the flipping type of the neighboring block is horizontal flipping, the single direction is a horizontal direction.

[0146] Clause 10. The method of clause 8, wherein if the flip type of the neighboring block is a vertical flip, the single direction is a vertical direction.

[0147] Clause 11. The method of any one of clauses 1 to 10, wherein the flip type of the current block is determined independently of the flip types of neighboring blocks.

[0148] Clause 12. The method of clause 11, wherein the flip type of the current block is no flip.

[0149] Clause 13. The method of any one of clauses 1 to 10, wherein the flip type of the current block is determined based on the flip types of neighboring blocks.

[0150] Clause 14. The method of clause 13, wherein the flipping type of the current block is the same as the flipping type of the neighboring block.

[0151] Clause 15. A method according to any one of clauses 1 to 14, wherein the video also includes another block different from the current block, the motion information of the other block is determined based on the IBC-MBVD mode independently of the motion information of another neighboring block of the other block, and the other neighboring block is encoded and decoded using the RRIBC mode.

[0152] Clause 16. The method of clause 15, wherein motion information of another block is not allowed to be used as a base motion candidate for the IBC-MBVD mode.

[0153] Clause 17. The method of any of clauses 15 to 16, wherein the further block is not allowed to be determined based on another neighboring block.

[0154] Clause 18. The method according to any one of clauses 15 to 17, wherein the motion information of the other neighboring block and the flip type of the other neighboring block are not allowed to be added to the motion candidate list for the other block.

[0155] Clause 19. The method of any one of clauses 15 to 18, wherein codec information of another neighboring block is not allowed to be added to the motion candidate list for the other block.

[0156] Clause 20. The method of any of clauses 15 to 16, wherein the flip type of the further block is determined based on the flip type of the further neighboring block.

[0157] Clause 21. A method according to any one of clauses 1 to 20, wherein if the current block is encoded and decoded using the RRIBC mode, a first set of MBVD offsets are allowed to be added to the base motion candidate for the IBC-MBVD mode, and if the current block is not encoded and decoded using the RRIBC mode, a second set of MBVD offsets are allowed to be added to the base motion candidate.

[0158] Clause 22. A method according to any one of clauses 1 to 20, wherein if a base motion candidate for an IBC-MBVD mode is encoded and decoded using an RRIBC mode, a first set of MBVD offsets is allowed to be added to the base motion candidate, and if the base motion candidate is not encoded and decoded using the RRIBC mode, a second set of MBVD offsets is allowed to be added to the base motion candidate.

[0159] Clause 23. The method of any of clauses 21 to 22, wherein the first set of MBVD offsets is different from the second set of MBVD offsets.

[0160] Clause 24. The method of any of clauses 21 to 22, wherein the first set of MBVD offsets is the same as the second set of MBVD offsets.

[0161] Clause 25. The method of any of clauses 21 to 23, wherein the first set of MBVD offsets is a subset of the second set of MBVD offsets.

[0162] Clause 26. A method according to any of clauses 1 to 20, wherein a set of MBVD offsets allowed to be added to a base motion candidate for IBC-MBVD mode depends on a flip type of the current block or a flip type of the base motion candidate.

[0163] Clause 27. The method of clause 26, wherein if the flip type of the current block is a horizontal flip, then the set of MBVD offsets comprises a set of horizontal MBVD offsets.

[0164] Clause 28. The method of clause 27, wherein the vertical component of each MBVD offset in the set of MBVD offsets is equal to zero.

[0165] Clause 29. The method of clause 26, wherein if the flip type of the current block is a vertical flip, then the set of MBVD offsets comprises a set of vertical MBVD offsets.

[0166] Clause 30. The method of clause 29, wherein a horizontal component of each MBVD offset in a set of MBVD offsets is equal to zero.

[0167] Clause 31. The method of clause 26, wherein if the flip type of the base motion candidate is a horizontal flip, then the set of MBVD offsets comprises a set of horizontal MBVD offsets.

[0168] Clause 32. The method of clause 31, wherein the vertical component of each MBVD offset in a set of MBVD offsets is equal to zero.

[0169] Clause 33. The method of clause 26, wherein if the flip type of the base motion candidate is a vertical flip, then the set of MBVD offsets comprises a set of vertical MBVD offsets.

[0170] Clause 34. The method of clause 33, wherein a horizontal component of each MBVD offset in a set of MBVD offsets is equal to zero.

[0171] Clause 35. A method according to any of clauses 1 to 34, wherein motion candidates for RRIBC codecs for IBC-MBVD mode and motion candidates for non-RRIBC codecs for IBC-MBVD mode are grouped into a single set of motion candidates.

[0172] Clause 36. The method of clause 35, wherein the indexing of motion candidates for the IBC-MBVD mode is encoded based on a single set of motion candidates.

[0173] Clause 37. The method of clause 35, wherein the motion candidates in the single set of motion candidates are ordered based on template costs of the motion candidates.

[0174] Clause 38. A method according to any one of clauses 1 to 34, wherein motion candidates for RRIBC codec for IBC-MBVD mode are grouped into a first group of motion candidates, and motion candidates for non-RRIBC codec for IBC-MBVD mode are grouped into a second group of motion candidates.

[0175] Clause 39. The method of clause 38, wherein indices of motion candidates for the IBC-MBVD mode are encoded based on the first set of motion candidates or the second set of motion candidates.

[0176] Clause 40. The method of clause 38, wherein the motion candidates in the first set of motion candidates or the second set of motion candidates are ordered based on template costs of the motion candidates.

[0177] Clause 41. A method according to any one of clauses 1 to 40, wherein if the current block is encoded and decoded using RRIBC, the flip type of the current block is not equal to no flip, and if the current block is not encoded and decoded using RRIBC, the flip type of the current block is equal to no flip.

[0178] Clause 42. A method for video processing, comprising: for conversion between a current block of a video and a bitstream of the video, determining motion information of the current block based on motion information of neighboring blocks of the current block and an intra-block copy template matching merge (IBC-TM-MERGE) mode, the current block and the neighboring blocks being encoded and decoded using a reconstruction reordered intra-block copy (RRIBC) mode; and performing conversion based on the motion information of the current block.

[0179] Clause 43. The method of clause 42, wherein the motion information of the current block is the same as the motion information of the neighboring block.

[0180] Clause 44. The method according to any one of clauses 42 to 43, wherein the flipping type of the current block is the same as the flipping type of the neighboring block.

[0181] Clause 45. The method of clause 42, wherein determining the motion information of the current block comprises generating the motion information of the current block by adjusting the motion information of neighboring blocks based on a motion adjustment process.

[0182] Clause 46. A method according to clause 42, wherein determining the motion information of the current block comprises: obtaining intermediate motion information by adjusting the motion information of neighboring blocks based on a motion adjustment process; and refining the intermediate motion information through a motion refinement process based on template matching to generate the motion information of the current block.

[0183] Clause 47. A method according to clause 42, wherein determining the motion information of the current block comprises: obtaining intermediate motion information by refining the motion information of neighboring blocks according to a motion refinement process based on template matching; and generating the motion information of the current block by adjusting the intermediate motion information based on a motion adjustment process.

[0184] Clause 48. The method of clause 42, wherein determining the motion information of the current block comprises generating the motion information of the current block by refining the motion information of neighboring blocks according to a template matching based motion refinement process.

[0185] Clause 49. A method according to any one of clauses 45 to 47, wherein the motion adjustment process depends on at least one of the following: the flipping type of the current block, the flipping type of the neighboring block, the position of the current block, the position of the neighboring block, the coordinates of the current block, or the coordinates of the neighboring block.

[0186] Clause 50. The method of any one of clauses 45 to 47 and 49, wherein the adjustment is performed in a single direction during a motion adjustment.

[0187] Clause 51. The method of clause 50, wherein if the flip type of the neighboring block is a horizontal flip, the single direction is a horizontal direction.

[0188] Clause 52. The method of clause 50, wherein if the flip type of the neighboring block is a vertical flip, the single direction is a vertical direction.

[0189] Clause 53. A method according to any one of clauses 46 to 48, wherein a set of motion vector (MV) offsets allowed for use in the template matching based motion refinement process depends on the flip type of the current block or the flip type of the motion candidate for the IBC-TM-MERGE mode.

[0190] Clause 54. The method of clause 53, wherein if the flip type of the current block is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

[0191] Clause 55. The method of clause 54, wherein the vertical component of each MV offset in a set of MV offsets is equal to zero.

[0192] Clause 56. The method of clause 53, wherein if the flip type of the motion candidate is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

[0193] Clause 57. The method of clause 56, wherein the vertical component of each MV offset in a set of MV offsets is equal to zero.

[0194] Clause 58. The method of clause 53, wherein if the flip type of the current block is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

[0195] Clause 59. The method of clause 58, wherein a horizontal component of each MV offset in a set of MV offsets is equal to zero.

[0196] Clause 60. The method of clause 53, wherein if the flip type of the motion candidate is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

[0197] Clause 61. The method of clause 60, wherein a horizontal component of each MV offset in a set of MV offsets is equal to zero.

[0198] Clause 62. A method for video processing, comprising: for conversion between a current block of a video and a bitstream of the video, determining a motion candidate for the current block based on motion information of neighboring blocks of the current block and an intra block copy advanced motion vector prediction (IBC-AMVP) mode, the neighboring blocks being encoded and decoded using a reconstruction reordered intra block copy (RRIBC) mode; determining motion information of the current block based on the motion candidate; and performing conversion based on the motion information of the current block.

[0199] Clause 63. The method of clause 62, wherein determining the motion information of the current block comprises generating the motion information of the current block by adjusting a motion vector of a motion candidate based on a motion adjustment process.

[0200] Clause 64. A method according to Clause 62, wherein determining the motion information of the current block comprises: obtaining an intermediate motion vector by adjusting the motion vector of the motion candidate based on a motion adjustment process; and generating the motion information of the current block by refining the intermediate motion vector according to a motion refinement process based on template matching.

[0201] Clause 65. A method according to Clause 62, wherein determining the motion information of the current block comprises: obtaining an intermediate motion vector by refining the motion vector of the motion candidate according to a motion refinement process based on template matching; and generating the motion information of the current block by adjusting the intermediate motion vector by a motion adjustment process based on motion.

[0202] Clause 66. The method of clause 62, wherein determining the motion information of the current block comprises generating the motion information of the current block by refining the motion vector of the motion candidate according to a template matching based motion refinement process.

[0203] Clause 67. A method according to any one of clauses 62 to 66, wherein the current block is not encoded using RRIBC mode.

[0204] Clause 68. A method according to any one of clauses 63 to 65, wherein the motion adjustment process depends on at least one of the following: the flipping type of the current block, the flipping type of the neighboring block, the position of the current block, the position of the neighboring block, the coordinates of the current block, or the coordinates of the neighboring block.

[0205] Clause 69. The method according to any one of clauses 63 to 65 and 68, wherein the adjustment is performed in a single direction during the motion adjustment.

[0206] Clause 70. The method of clause 69, wherein if the flip type of the neighboring block is a horizontal flip, the single direction is a horizontal direction.

[0207] Clause 71. The method of clause 69, wherein if the flip type of the neighboring block is a vertical flip, the single direction is a vertical direction.

[0208] Clause 72. A method according to any of clauses 64 to 56, wherein a set of motion vector (MV) offsets allowed for use in the template matching based motion refinement process depends on a flip type of the current block or a flip type of a motion candidate.

[0209] Clause 73. The method of clause 72, wherein if the flip type of the current block is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

[0210] Clause 74. The method of clause 73, wherein the vertical component of each MV offset in a set of MV offsets is equal to zero.

[0211] Clause 75. The method of clause 72, wherein if the flip type of the motion candidate is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

[0212] Clause 76. The method of clause 75, wherein the vertical component of each MV offset in a set of MV offsets is equal to zero.

[0213] Clause 77. The method of clause 72, wherein if the flip type of the current block is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

[0214] Clause 78. The method of clause 77, wherein the horizontal component of each MV offset in a set of MV offsets is equal to zero.

[0215] Clause 79. The method of clause 72, wherein if the flip type of the motion candidate is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

[0216] Clause 80. The method of clause 79, wherein a horizontal component of each MV offset in a set of MV offsets is equal to zero.

[0217] Clause 81. A method according to any of clauses 1 to 80, wherein in RRIBC mode the adjustment is applied to the reconstructed samples of the neighbouring blocks.

[0218] Clause 82. The method of clause 81, wherein adjusting comprises at least one of: reordering the reconstructed samples, flipping the reconstructed samples, moving the reconstructed samples, rotating the reconstructed samples, or transforming the reconstructed samples.

[0219] Clause 83. A method according to any one of clauses 1 to 82, wherein the current block is one of the following: a color component, a sub-picture, a slice, a tile, a codec tree unit (CTU), a CTU row, a group of CTUs, a codec unit (CU), a prediction unit (PU), a transform unit (TU), a codec tree block (CTB), a codec block (CB), a prediction block (PB), a transform block (TB), a sub-block of a video block, or a sub-region within a video block.

[0220] Clause 84. A method according to any of clauses 1 to 82, wherein whether and / or how to apply the method is indicated at one of: sequence level, group of picture level, picture level, slice level, or tile group level.

[0221] Clause 85. A method according to any one of clauses 1 to 82, wherein whether and / or how the method is applied is indicated in one of the following: a sequence header, a picture header, a sequence parameter set (SPS), a video parameter set (VPS), a dependency parameter set (DPS), decoding capability information (DCI), a picture parameter set (PPS), an adaptation parameter set (APS), a slice header, or a tile group header.

[0222] Clause 86. A method according to any one of clauses 1 to 85, wherein converting comprises encoding the current block into a bitstream.

[0223] Clause 87. A method according to any one of clauses 1 to 85, wherein converting comprises decoding the current block from a bitstream.

[0224] Clause 88. 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 of any one of clauses 1 to 87.

[0225] Clause 89. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method of any one of clauses 1 to 87.

[0226] Item 90. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method executed by a device for video processing, wherein the method comprises: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-MBVD mode, the neighboring blocks being encoded and decoded using an RRIBC mode; and generating a bitstream based on the motion information of the current block.

[0227] Clause 91. A method for storing a bitstream of a video, comprising: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-MBVD mode, the neighboring blocks being encoded and decoded using an RRIBC mode; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium.

[0228] Item 92. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method executed by a device for video processing, wherein the method comprises: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-TM-MERGE mode, the current block and the neighboring blocks being encoded and decoded using an RRIBC mode; and generating a bitstream based on the motion information of the current block.

[0229] Clause 93. A method for storing a bitstream of a video, comprising: determining motion information of a current block based on motion information of neighboring blocks of the current block of the video and an IBC-TM-MERGE mode, the current block and the neighboring blocks being encoded and decoded using an RRIBC mode; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium.

[0230] Item 94. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method executed by a device for video processing, wherein the method comprises: determining motion candidates for a current block of the video based on motion information of neighboring blocks of the current block of the video and an IBC-AMVP mode, the neighboring blocks being encoded and decoded using an RRIBC mode; determining motion information of the current block based on the motion candidates; and generating a bitstream based on the motion information of the current block.

[0231] Clause 95. A method for storing a bitstream of a video, comprising: determining motion candidates for a current block based on motion information of neighboring blocks of a current block of the video and an IBC-AMVP mode, the neighboring blocks being encoded and decoded using an RRIBC mode; determining motion information of the current block based on the motion candidates; generating a bitstream based on the motion information of the current block; and storing the bitstream in a non-transitory computer-readable recording medium. Example Device

[0232] Fig.15 A block diagram of a computing device 1500 in which various embodiments of the present disclosure may be implemented is shown. The computing device 1500 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).

[0233] It should be understood that Fig.15 The computing device 1500 shown in FIG. 1 is for illustrative purposes only and is not intended to in any way imply any limitation on the functionality and scope of the embodiments of the present disclosure.

[0234] like Fig.15 As shown, computing device 1500 includes a general computing device 1500. Computing device 1500 may include at least one or more processors or processing units 1510, memory 1520, storage unit 1530, one or more communication units 1540, one or more input devices 1550, and one or more output devices 1560.

[0235] In some embodiments, computing device 1500 can be implemented as any user terminal or server terminal with computing capability. The server terminal can be a server provided by a service provider, a large computing device, etc. The user terminal can be, for example, any type of mobile terminal, fixed terminal or portable terminal, including a mobile phone, a station, a unit, a device, a multimedia computer, a multimedia tablet computer, an Internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a personal communication system (PCS) device, a personal navigation device, a personal digital assistant (PDA), an audio / video player, a digital camera / camcorder, a positioning device, a television receiver, a radio broadcast receiver, an electronic book device, a gaming device, or any combination thereof, and includes the accessories and peripherals of these devices, or any combination thereof. It is conceivable that computing device 1500 can support any type of interface to the user (such as a "wearable" circuit device, etc.).

[0236] Processing unit 1510 may be a physical processor or a virtual processor and may implement various processes based on a program stored in memory 1520. In a multi-processor system, multiple processing units execute computer executable instructions in parallel to improve the parallel processing capability of computing device 1500. Processing unit 1510 may also be referred to as a central processing unit (CPU), a microprocessor, a controller, or a microcontroller.

[0237] The computing device 1500 typically includes various computer storage media. Such media can be any media accessible by the computing device 1500, including but not limited to volatile media and non-volatile media, or removable media and non-removable media. The memory 1520 can be a volatile memory (e.g., a register, a cache, a random access memory (RAM)), a non-volatile memory (such as a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM) or flash memory) or any combination thereof. The storage unit 1530 can be any removable or non-removable medium, and can include machine-readable media, such as a memory, a flash drive, a disk, or other media that can be used to store information and / or data and can be accessed in the computing device 1500.

[0238] The computing device 1500 may also include additional removable / non-removable storage media, volatile / non-volatile storage media. Fig.15 Although not shown in the figure, a magnetic disk drive for reading from and / or writing to a removable nonvolatile magnetic disk and an optical disk drive for reading from and / or writing to a removable nonvolatile optical disk may be provided. In this case, each drive may be connected to the bus (not shown) via one or more data medium interfaces.

[0239] The communication unit 1540 communicates with another computing device via a communication medium. In addition, the functionality of the components in the computing device 1500 can be implemented by a single computing cluster or multiple computing machines that can communicate via a communication connection. Therefore, the computing device 1500 can operate in a networked environment using logical connections to one or more other servers, networked personal computers (PCs), or other general network nodes.

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

[0241] In some embodiments, some or all components of the computing device 1500 may also be arranged in a cloud computing architecture rather than being integrated in a single device. In a cloud computing architecture, components may be provided remotely and work together to implement the functions described in the present disclosure. In some embodiments, cloud computing provides computing, software, data access and storage services, which will not require the end user to know the physical location or configuration of the system or hardware that provides these services. In various embodiments, cloud computing provides services via a wide area network (e.g., the Internet) using a suitable protocol. For example, a cloud computing provider provides applications via a wide area network, which can be accessed through a web browser or any other computing component. The software or components of the cloud computing architecture and the corresponding data may be stored on a remote server. The computing resources in a cloud computing environment may be merged or distributed at the location of a remote data center. Cloud computing infrastructures may provide services through a shared data center, although they appear as a single access point for users. Therefore, cloud computing architectures may be used to provide components and functions described herein from a service provider at a remote location. Alternatively, they may be provided by a conventional server, or installed directly or otherwise on a client device.

[0242] In an embodiment of the present disclosure, the computing device 1500 may be used to implement video encoding / decoding. The memory 1520 may include one or more video encoding / decoding modules 1525 having one or more program instructions. These modules can be accessed and executed by the processing unit 1510 to perform the functions of the various embodiments described herein.

[0243] In an example embodiment performing video encoding, input device 1550 may receive video data as input 1570 to be encoded. The video data may be processed by, for example, video codec module 1525 to generate an encoded bitstream. The encoded bitstream may be provided as output 1580 via output device 1560.

[0244] In an example embodiment performing video decoding, input device 1550 may receive an encoded bitstream as input 1570. The encoded bitstream may be processed by, for example, video codec module 1525 to generate decoded video data. The decoded video data may be provided as output 1580 via output device 1560.

[0245] Although the present disclosure has been specifically shown and described with reference to the preferred embodiments of the present disclosure, it will be understood by those skilled in the art that various changes can be made in form and detail without departing from the spirit and scope of the present application as defined by the appended claims. These changes are intended to be encompassed by the scope of the present application. Therefore, the foregoing description of the embodiments of the present application is not intended to be limiting.

Claims

1. A method for video processing, comprising: For conversion between a current block of a video and a bitstream of the video, determining motion information of the current block based on motion information of neighboring blocks of the current block and an intra-frame block copy merge mode with block vector difference (IBC-MBVD) mode, the neighboring blocks being encoded and decoded using a reconstruction reordered intra-frame block copy (RRIBC) mode; as well as The converting is performed based on the motion information of the current block. 2 . The method of claim 1 , wherein the motion information of the neighboring blocks is used as a base motion candidate for the IBC-MBVD mode.

3. The method of claim 1 , wherein determining the motion information of the current block comprises: adjusting the motion information of the neighboring blocks based on a motion adjustment process; as well as The motion information of the current block is generated based on the adjusted motion information and the IBC-MBVD mode, the adjusted motion information being used as a base motion candidate for the IBC-MBVD mode. The method according to claim 3 , wherein in the motion adjustment process, a motion displacement is added to the motion information of the current block.

5. The method of claim 1 , wherein determining the motion information of the current block comprises: determining intermediate motion information based on the motion information of the neighboring blocks and the IBC-MBVD mode, the motion information of the neighboring blocks being used as a base motion candidate for the IBC-MBVD mode; as well as The motion information of the current block is generated by adjusting the intermediate motion information based on a motion adjustment process. The method according to claim 5 , wherein a motion displacement is added to the intermediate motion information during the motion adjustment process.

7. The method according to any one of claims 3 to 6, wherein the motion adjustment process depends on at least one of the following: The flip type of the current block, The flip type of the neighboring block, The position of the current block, The location of the neighboring blocks, the coordinates of the current block, or The coordinates of the neighboring blocks.

8. The method according to any one of claims 3 to 7, wherein the adjustment is performed in a single direction during the movement adjustment. 9 . The method according to claim 8 , wherein if the flipping type of the neighboring block is horizontal flipping, the single direction is a horizontal direction.

10. The method of claim 8, wherein if the flipping type of the neighboring block is a vertical flipping, the single direction is a vertical direction.

11. The method according to any one of claims 1 to 10, wherein the flipping type of the current block is determined independently of the flipping type of the neighboring blocks. The method according to claim 11 , wherein the flipping type of the current block is no flipping.

13. The method according to any one of claims 1 to 10, wherein the flipping type of the current block is determined based on the flipping type of the neighboring block. The method of claim 13 , wherein the flipping type of the current block is the same as the flipping type of the neighboring block.

15. The method according to any one of claims 1 to 14, wherein the video also includes another block different from the current block, the motion information of the other block is determined based on the IBC-MBVD mode independently of the motion information of another neighboring block of the other block, and the other neighboring block is encoded and decoded using the RRIBC mode. The method of claim 15 , wherein the motion information of the another block is not allowed to be used as a base motion candidate for the IBC-MBVD mode.

17. The method according to any one of claims 15 to 16, wherein the further block is not allowed to be determined based on the further neighboring block. 18 . The method according to claim 15 , wherein the motion information of the another neighboring block and the flipping type of the another neighboring block are not allowed to be added to a motion candidate list for the another block.

19. The method according to any one of claims 15 to 18, wherein the codec information of the another neighboring block is not allowed to be added to the motion candidate list for the another block.

20. The method according to any one of claims 15 to 16, wherein the flipping type of the another block is determined based on the flipping type of the another neighboring block.

21. The method according to any one of claims 1 to 20, wherein if the current block is encoded using the RRIBC mode, a first set of MBVD offsets are allowed to be added to the base motion candidate for the IBC-MBVD mode, If the current block is not encoded using the RRIBC mode, a second set of MBVD offsets are allowed to be added to the base motion candidates.

22. The method according to any one of claims 1 to 20, wherein if a base motion candidate for the IBC-MBVD mode is coded using the RRIBC mode, a first set of MBVD offsets is allowed to be added to the base motion candidate, If the base motion candidate is not coded using the RRIBC mode, a second set of MBVD offsets is allowed to be added to the base motion candidate.

23. The method of any one of claims 21 to 22, wherein the first set of MBVD offsets is different from the second set of MBVD offsets.

24. The method of any one of claims 21 to 22, wherein the first set of MBVD offsets is the same as the second set of MBVD offsets.

25. The method of any one of claims 21 to 23, wherein the first set of MBVD offsets is a subset of the second set of MBVD offsets.

26. The method according to any one of claims 1 to 20, wherein a set of MBVD offsets allowed to be added to a base motion candidate for the IBC-MBVD mode depends on a flip type of the current block or a flip type of the base motion candidate.

27. The method of claim 26, wherein if the flip type of the current block is a horizontal flip, then the set of MBVD offsets comprises a set of horizontal MBVD offsets.

28. The method of claim 27, wherein a vertical component of each MBVD offset in the set of MBVD offsets is equal to zero.

29. The method of claim 26, wherein if the flip type of the current block is a vertical flip, then the set of MBVD offsets comprises a set of vertical MBVD offsets.

30. The method of claim 29, wherein a horizontal component of each MBVD offset in the set of MBVD offsets is equal to zero.

31. The method of claim 26, wherein if the flip type of the base motion candidate is a horizontal flip, then the set of MBVD offsets comprises a set of horizontal MBVD offsets.

32. The method of claim 31, wherein a vertical component of each MBVD offset in the set of MBVD offsets is equal to zero.

33. The method of claim 26, wherein if the flip type of the base motion candidate is a vertical flip, then the set of MBVD offsets comprises a set of vertical MBVD offsets.

34. The method of claim 33, wherein a horizontal component of each MBVD offset in the set of MBVD offsets is equal to zero.

35. The method according to any one of claims 1 to 34, wherein motion candidates for RRIBC codec of the IBC-MBVD mode and motion candidates for non-RRIBC codec of the IBC-MBVD mode are grouped into a single set of motion candidates.

36. The method of claim 35, wherein indexes of motion candidates for the IBC-MBVD mode are encoded based on the single set of motion candidates.

37. The method of claim 35, wherein the motion candidates in the single set of motion candidates are ordered based on template costs of the motion candidates.

38. The method according to any one of claims 1 to 34, wherein motion candidates for RRIBC encoding and decoding of the IBC-MBVD mode are grouped into a first group of motion candidates, and motion candidates for non-RRIBC encoding and decoding of the IBC-MBVD mode are grouped into a second group of motion candidates.

39. The method of claim 38, wherein indices of motion candidates for the IBC-MBVD mode are encoded based on the first set of motion candidates or the second set of motion candidates.

40. The method of claim 38, wherein the motion candidates in the first set of motion candidates or the second set of motion candidates are ranked based on template costs of the motion candidates.

41. The method according to any one of claims 1 to 40, wherein if the current block is encoded and decoded using RRIBC, the flip type of the current block is not equal to no flip, If the current block is not encoded and decoded using RRIBC, the flip type of the current block is equal to no flip.

42. A method for video processing, comprising: For conversion between a current block of a video and a bitstream of the video, determining motion information of the current block based on motion information of neighboring blocks of the current block and an intra-block copy template matching merge (IBC-TM-MERGE) mode, the current block and the neighboring blocks being encoded and decoded using a reconstruction reordered intra-block copy (RRIBC) mode; as well as The converting is performed based on the motion information of the current block.

43. The method of claim 42, wherein the motion information of the current block is the same as the motion information of the neighboring block.

44. The method according to any one of claims 42 to 43, wherein the flipping type of the current block is the same as the flipping type of the neighboring block.

45. The method of claim 42, wherein determining the motion information of the current block comprises: The motion information of the current block is generated by adjusting the motion information of the neighboring blocks based on a motion adjustment process.

46. ​​The method of claim 42, wherein determining the motion information of the current block comprises: Acquire intermediate motion information by adjusting the motion information of the neighboring blocks based on a motion adjustment process; as well as The intermediate motion information is refined through a motion refinement process based on template matching to generate the motion information of the current block.

47. The method of claim 42, wherein determining the motion information of the current block comprises: Obtaining intermediate motion information by refining the motion information of the neighboring blocks according to a motion refinement process based on template matching; as well as The motion information of the current block is generated by adjusting the intermediate motion information based on a motion adjustment process.

48. The method of claim 42, wherein determining the motion information of the current block comprises: The motion information of the current block is generated by refining the motion information of the neighboring blocks according to a template matching based motion refinement process.

49. The method according to any one of claims 45 to 47, wherein the motion adjustment process depends on at least one of the following: The flip type of the current block, The flip type of the neighboring block, The position of the current block, The location of the neighboring blocks, the coordinates of the current block, or The coordinates of the neighboring blocks.

50. A method according to any one of claims 45 to 47 and 49, wherein said adjusting is performed in a single direction during said movement adjustment.

51. The method of claim 50, wherein if the flipping type of the neighboring block is a horizontal flipping, the single direction is a horizontal direction.

52. The method of claim 50, wherein if the flipping type of the neighboring block is a vertical flipping, the single direction is a vertical direction.

53. A method according to any one of claims 46 to 48, wherein a set of motion vector (MV) offsets allowed for use in the template matching based motion refinement process depends on the flip type of the current block or the flip type of the motion candidate for the IBC-TM-MERGE mode.

54. The method of claim 53, wherein if the flip type of the current block is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

55. The method of claim 54, wherein a vertical component of each MV offset in the set of MV offsets is equal to zero.

56. The method of claim 53, wherein if the flip type of the motion candidate is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

57. The method of claim 56, wherein a vertical component of each MV offset in the set of MV offsets is equal to zero.

58. The method of claim 53, wherein if the flip type of the current block is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

59. The method of claim 58, wherein a horizontal component of each MV offset in the set of MV offsets is equal to zero.

60. The method of claim 53, wherein if the flip type of the motion candidate is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

61. The method of claim 60, wherein a horizontal component of each MV offset in the set of MV offsets is equal to zero.

62. A method for video processing, comprising: For conversion between a current block of a video and a bitstream of the video, determining a motion candidate for the current block based on motion information of neighboring blocks of the current block and an intra block copy advanced motion vector prediction (IBC-AMVP) mode, wherein the neighboring blocks are encoded and decoded using a reconstruction reordered intra block copy (RRIBC) mode; Determine motion information of the current block based on the motion candidate; as well as The converting is performed based on the motion information of the current block.

63. The method of claim 62, wherein determining the motion information of the current block comprises: The motion information of the current block is generated by adjusting the motion vector of the motion candidate based on a motion adjustment process.

64. The method of claim 62, wherein determining the motion information of the current block comprises: Acquire an intermediate motion vector by adjusting the motion vector of the motion candidate based on a motion adjustment process; The motion information of the current block is generated by refining the intermediate motion vector according to a motion refinement process based on template matching.

65. The method of claim 62, wherein determining the motion information of the current block comprises: Obtaining an intermediate motion vector by refining the motion vector of the motion candidate according to a motion refinement process based on template matching; The motion information of the current block is generated by adjusting the intermediate motion vector based on a motion adjustment process.

66. The method of claim 62, wherein determining the motion information of the current block comprises: The motion information of the current block is generated by refining the motion vector of the motion candidate according to a motion refinement process based on template matching.

67. The method according to any one of claims 62 to 66, wherein the current block is encoded and decoded without using the RRIBC mode.

68. The method of any one of claims 63 to 65, wherein the motion adjustment process depends on at least one of: The flip type of the current block, The flip type of the neighboring block, The position of the current block, The location of the neighboring blocks, the coordinates of the current block, or The coordinates of the neighboring blocks.

69. A method according to any one of claims 63 to 65 and 68, wherein the adjustment is performed in a single direction during the movement adjustment process.

70. The method of claim 69, wherein if the flipping type of the neighboring block is a horizontal flipping, the single direction is a horizontal direction.

71. The method of claim 69, wherein if the flipping type of the neighboring block is a vertical flipping, the single direction is a vertical direction.

72. The method of any one of claims 64 to 56, wherein a set of motion vector (MV) offsets allowed for use in the template matching based motion refinement process depends on a flip type of the current block or a flip type of the motion candidate.

73. The method of claim 72, wherein if the flip type of the current block is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

74. The method of claim 73, wherein a vertical component of each MV offset in the set of MV offsets is equal to zero.

75. The method of claim 72, wherein if the flip type of the motion candidate is a horizontal flip, the set of MV offsets comprises a set of horizontal MV offsets.

76. The method of claim 75, wherein a vertical component of each MV offset in the set of MV offsets is equal to zero.

77. The method of claim 72, wherein if the flip type of the current block is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

78. The method of claim 77, wherein a horizontal component of each MV offset in the set of MV offsets is equal to zero.

79. The method of claim 72, wherein if the flip type of the motion candidate is a vertical flip, the set of MV offsets comprises a set of vertical MV offsets.

80. The method of claim 79, wherein a horizontal component of each MV offset in the set of MV offsets is equal to zero.

81. A method according to any one of claims 1 to 80, wherein in the RRIBC mode adjustment is applied to reconstructed samples of the neighboring blocks.

82. The method of claim 81, wherein the adjusting comprises at least one of: reordering the reconstructed samples, flipping the reconstructed sample, moving the reconstruction sample, Rotate the reconstructed sample, or Transform the reconstructed sample.

83. The method of any one of claims 1 to 82, wherein the current block is one of: Color components, Sub-picture, Strips, Tile, Codec Tree Unit (CTU), CTU line, The CTU group, Codec Unit (CU), Prediction Unit (PU), Transformation Unit (TU), Codec Tree Block (CTB), Codec Block (CB), Prediction Block (PB), Transform Block (TB), A sub-block of a video block, or A sub-region within a video block.

84. A method according to any one of claims 1 to 82, wherein whether and / or how to apply the method is indicated at one of: Sequence level, Picture group level, Picture level, Stripe level, or Tile group level.

85. The method of any one of claims 1 to 82, wherein whether and / or how to apply the method is indicated in one of: Sequence header, Picture header, Sequence Parameter Set (SPS), Video Parameter Set (VPS), Dependency Parameter Set (DPS), Decoding Capability Information (DCI), Picture Parameter Set (PPS), Adaptive Parameter Set (APS), Strip header, or Tile group header.

86. A method according to any one of claims 1 to 85, wherein the converting comprises encoding the current block into the bitstream.

87. The method of any one of claims 1 to 85, wherein the converting comprises decoding the current block from the bitstream.

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

89. 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 87.

90. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method performed by an apparatus for video processing, wherein the method comprises: Determining motion information of a current block of the video based on motion information of neighboring blocks of the current block and an IBC-MBVD mode, the neighboring blocks being encoded and decoded using an RRIBC mode; as well as The bitstream is generated based on the motion information of the current block.

91. A method for storing a bitstream of a video, comprising: Determining motion information of a current block of the video based on motion information of neighboring blocks of the current block and an IBC-MBVD mode, the neighboring blocks being encoded and decoded using an RRIBC mode; generating the bitstream based on motion information of the current block; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

92. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method performed by an apparatus for video processing, wherein the method comprises: Determine the motion information of the current block of the video based on the motion information of the neighboring blocks and the IBC-TM-MERGE mode, the current block and the neighboring blocks being encoded and decoded using the RRIBC mode; as well as The bitstream is generated based on the motion information of the current block.

93. A method for storing a bitstream of a video, comprising: Determine the motion information of the current block of the video based on the motion information of the neighboring blocks and the IBC-TM-MERGE mode, the current block and the neighboring blocks being encoded and decoded using the RRIBC mode; generating the bitstream based on motion information of the current block; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

94. A non-transitory computer-readable storage medium storing a bitstream of a video, the bitstream of the video being generated by a method performed by an apparatus for video processing, wherein the method comprises: Determine a motion candidate for the current block based on motion information of a neighboring block of the current block of the video and an IBC-AMVP mode, the neighboring block being encoded and decoded using an RRIBC mode; Determine motion information of the current block based on the motion candidate; as well as The bitstream is generated based on the motion information of the current block.

95. A method for storing a bitstream of a video, comprising: Determine a motion candidate for the current block based on motion information of a neighboring block of the current block of the video and an IBC-AMVP mode, the neighboring block being encoded and decoded using an RRIBC mode; Determine motion information of the current block based on the motion candidate; generating the bitstream based on the motion information of the current block; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

Images