Method and device for video processing and medium

Abstract

Embodiments of the present disclosure provide a scheme for video processing. A method for video processing is presented. The method includes, for a conversion between a video unit of a video and a bitstream of the video, generating an intra mode for the video unit based on codec information associated with the video unit, where the video unit is an intra template matching (TM) codec block or the video unit is an intra copy block (IBC) codec block; and performing a transition based on the generated intra mode.

Description

Technical Field

[0001] The embodiments of the present disclosure generally relate to video processing technology, and more specifically, to context adaptive variable length coding (CABAC) initialization, intra block copy (IBC), intra template matching (TM), screen content coding (SCC) and chroma sample reordering in image / video coding. 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-T H.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 efficiency of video encoding and decoding technologies can be further improved. Summary of the invention

[0003] The embodiment of the present disclosure provides a video processing solution.

[0004] In a first aspect, a method for video processing is proposed. The method includes: for conversion between a video unit of a video and a bit stream of the video, generating an intra-frame mode for the video unit based on codec information associated with the video unit, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; and performing conversion based on the generated intra-frame mode. This can improve codec efficiency.

[0005] In a second aspect, another method for video processing is provided. The method includes: for conversion between a video unit of a video and a bitstream of the video, determining at least one codec tool for which screen content codec for the video unit is to be disabled; and performing the conversion based on the determination. This can improve codec efficiency.

[0006] In a third 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 or the second aspect of the present disclosure.

[0007] In a fourth aspect, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores instructions for causing a processor to execute instructions of the method according to the first aspect or the second aspect of the present disclosure.

[0008] In a fifth aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video, and the bitstream of the video is generated by a method performed by a device for video processing. The method includes: generating an intra-frame mode for a video unit based on codec information associated with the video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; and generating a bitstream based on the generated intra-frame mode.

[0009] In a sixth aspect, a method for storing a bitstream of a video is provided, the method comprising: generating an intra-frame mode for a video unit based on codec information associated with the video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; generating a bitstream based on the generated intra-frame mode; and storing the bitstream in a non-transitory computer-readable recording medium.

[0010] In a seventh aspect, another non-transitory computer-readable medium is provided. The non-transitory computer-readable medium stores a bitstream of a video, and the bitstream of the video is generated by a method performed by an apparatus for video processing. The method includes: determining at least one codec tool for which screen content codec of a video unit of the video is to be disabled; and generating a bitstream based on the determination.

[0011] In an eighth aspect, a method for storing a bitstream of a video is provided, the method comprising: determining at least one codec tool for which screen content codec of a video unit of the video is to be disabled; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

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

[0013] 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.

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

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

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

[0017] Figure 4 An example of the current CTU processing order and its available reference samples in the current and left CTUs is shown;

[0018] Figure 5 An example of a residual encoding and decoding pass for transforming a skipped block is shown;

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

[0020] Figure 7 A sub-block based index map scan for a palette is shown, the left side for horizontal scanning and the right side for vertical scanning;

[0021] Figure 8 An example of a decoding flow chart with ACT is shown;

[0022] Fig. 9 shows an example of the intra-frame template matching search area used;

[0023] Fig.10 shows a flow chart for decoding binary bits;

[0024] Fig.11 An example of a residual codec structure for a transform block is shown;

[0025] Fig.12 An example of a template for selecting a probabilistic model is shown, where the black square specifies the current scan position and the grey square represents the local neighborhood used;

[0026] Fig.13 A schematic diagram showing a template and a reference sample of the template in a reference picture;

[0027] Fig.14 A schematic diagram showing a template of a block having sub-block motion and a reference sample of the template using motion information of a sub-block of a current block;

[0028] Fig.15 An example of pruning invalid BV candidates into valid BV candidates is shown;

[0029] Fig.16 A schematic diagram showing a first example of performing motion vector adjustment (horizontal flipping) according to motion vectors of neighboring blocks;

[0030] Fig.17 A schematic diagram showing a second example of performing motion vector adjustment (vertical flipping) according to motion vectors of neighboring blocks;

[0031] Fig.18 A schematic diagram showing a third example of performing motion vector adjustment (horizontal flipping) according to motion vectors of neighboring blocks;

[0032] Fig.19 A schematic diagram showing a fourth example of performing motion vector adjustment (vertical flipping) based on motion vectors of neighboring blocks.

[0033] Fig. 20A A schematic diagram showing a first example of template matching based on sample reordering;

[0034] Fig. 20B A schematic diagram showing a second example of template matching based on sample reordering;

[0035] Fig. 20C A schematic diagram showing a third example of template matching based on sample reordering;

[0036] Fig.20D A schematic diagram showing a fourth example of template matching based on sample reordering;

[0037] Fig.20E A schematic diagram showing a fifth example of template matching based on sample reordering;

[0038] Fig.20F A schematic diagram showing a sixth example of template matching based on sample reordering;

[0039] Figure 20G A schematic diagram showing a seventh example of template matching based on sample reordering;

[0040] Fig. 20H A schematic diagram showing an eighth example of template matching based on sample reordering;

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

[0042] Fig. 22 A flowchart showing a method for video processing according to an embodiment of the present disclosure; and

[0043] Fig.23 shows a block diagram of a computing device in which various embodiments of the present disclosure may be implemented;

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

[0045] 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, and do not imply 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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

[0050] 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.

[0051] 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.

[0052] 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.

[0053] The destination device 120 may include an I / O interface 126, a video decoder 124, and a display device 122. The I / O interface 126 may include a receiver and / or a modem. The I / O interface 126 may 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.

[0054] 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.

[0055] 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.

[0056] 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.

[0057] 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.

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

[0059] 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 in the following. Figure 2 are shown separately in the example.

[0060] 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.

[0061] The mode selection unit 203 may select one of a plurality of codec modes (intra or inter), for example, based on the error result, and provide the generated intra codec block or inter 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 and inter prediction (CIIP) modes, where the prediction is based on an inter prediction signal and an intra prediction signal. In the case of inter 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

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

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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, about context / CABAC initialization, intra-frame block copy and / or current picture reference 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 coding 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 (Higher Education Video Codec, 4th edition, Rec. ITU-T H.265, ISO / IEC 23008-2, December 2016) standards. Since H.262, video codec standards have been based on a hybrid video codec structure, which uses temporal prediction plus transform codec. 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. 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 (VTM software: https: / / vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM.git) are updated after each meeting. The VVC project achieved technical completion (FDIS) at the July 2020 meeting (Versatile Video Codec, Version 1, Rec.ITU-T H.266, ISO / IEC FDIS23090-3, July 2020). 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 codec 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 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 reference samples in the upper right 64×64 block of the left 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 can also refer to the reference samples in the lower right 64×64 block of the left CTU. – If the current block falls into the 64×64 block at 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 can also use the CPR mode to refer to the 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 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 as 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 virtual buffer concept is used to describe the allowable reference area for IBC prediction mode and valid block vectors. 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; for a CTU of size 64×64, the size of ibcBuf is 256×64; and 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), W v =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 an invalid value of -1. - When starting to decode a VPDU (xVPDU, yVPDU) relative to the top left corner of the picture, set ibcBuf[x][y]=-1, where x=xVPDU%wIbcBuf,...,xVPDU%wIbcBuf+W v -1; y=yVPDU%ctbSize,…,yVPDU%ctbSize+W v -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 Codec Modulation (BDPCM) for screen content coding and decoding. 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: If using vertical BDPCM (2-3) If using horizontal BDPCM (2-4) 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 scanning order is applied to scan sub-blocks within a transformed block and also to scan positions within the sub-blocks; - no signaling of the last (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 depends on the top and left neighboring values; -abs_level_gt1 flag's context model also depends on the left and above sig_coeff_flag values; - par_level_flag to use only one context model; - signaling additional greater than 3, 5, 7, 9 flags to indicate coefficient levels, with one context for each flag; - Binarization for the remainder values ​​derived using Rice parameters of 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, then 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, then 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, respectively. - 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 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 encoding and decoding pass, 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: 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 locations 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 with 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 . 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 the run type COPY_ABOVE, or whether the previously scanned sample and the current sample both have the 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 codec pass, index values ​​(for INDEX mode) and quantized escape colors are grouped and encoded using CABAC bypass codec in another codec pass. This separation of context codec binary bits and bypass codec 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 with a single tree, the palette is applied on the Y, Cb, Cr components jointly, 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 luma components but no chroma components due to chroma subsamples, then only the luma escape value is signaled. This is the same as in HEVC SCC. 2. For a local dual-tree block, the palette pattern is applied to the block in the same way as the palette pattern applied to a single T-shaped block with two exceptions: a. The process of palette predictor update is slightly modified as follows. Since the local dual-tree block contains only luma (or chroma) components, the predictor update process uses the signaled value of the luma (or chroma) component and fills in the "missing" chroma (or luma) component by setting it to a default value (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, in order to derive the initial entries in the palette table of the current CU, a simplified K-means clustering is applied. The palette table of the current CU is initialized to an empty table. For each sample position in the CU, the SAD between the sample and each palette table entry is calculated, and the minimum SAD among all palette table entries is obtained. 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-related 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 palette table thus generated contains some new entries from the centroids of the clusters in step 1, and some entries from the palette predictor. Therefore, the table is reordered again so that all new entries (i.e., centroids) are placed at the beginning of the table, followed by entries from the palette predictor. Given the palette table of the current CU, the encoder selects a 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 8 A 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 enabled only 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. - Reuse the same ACT enable / disable decision when a CU is obtained through different split paths. 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 split path, instead of checking the RD cost of the two spaces, the stored color space decision will be directly reused. -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. The prediction signal is generated by matching the L-shaped causal neighbors of the current block with another block in a predefined search area consisting of: R1: current CTU; R2: upper left CTU; R3: upper 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 (Search Range_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. Fig. 9 The intra template matching search area used is shown. The intra template matching tool is enabled in 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.2 Existing Entropy Coding and Decoding Technology 2.2.1 Core CABAC Engine The CABAC engine in HEVC uses a table-based probability conversion process between 64 different representative probability states. In HEVC, the range ivlCurrRange representing the state of the codec engine is quantized to a set of 4 values ​​before calculating the new interval range. HEVC state transitions can be implemented using a table containing all 64x48-bit pre-calculated values ​​to approximate the value of ivlCurrRange*pLPS(pStateIdx), where pLPS is the probability of the least likely symbol (LPS) and pStateIdx is the index of the current state. Moreover, a pre-calculated LUT can be used to implement decoding decisions. The first ivlLpsRange is obtained using the following LUT. Then, ivlLpsRange is used to update ivlCurrRange and calculate the output binVal. ivlLpsRange=rangeTableLps[pStateIdx][qRangeIdx] (2-7) In VVC, the probability is expressed linearly by the probability index pStateIdx. Therefore, all calculations can be done using equations without LUT operations. In order to improve the accuracy of the probability estimate, a multi-hypothesis probability update model is applied. The pStateIdx used in the interval subdivision in the binary arithmetic codec is a combination of two probabilities pStateIdx0 and pStateIdxl. The two probabilities are associated with each context model and are updated independently with different adaptation rates. The adaptation rates of pStateIdx0 and pStateIdx1 for each context model are pre-trained based on the statistics of the associated binary bits. The probability estimate pStateIdx is the average of the estimates from the two hypotheses. Fig.10 A flow chart for decoding a single binary decision in VVC is shown. As done in HEVC, VVC CABAC also has a QP-dependent initialization process called at the beginning of each slice. Given an initial value of the luma QP for the slice, the initial probability state of the context model (denoted as preCtxState) is derived as follows: m=slopeIdx×5-45 (2-8) n=(offsetIdx<<3)+7 (2-9) preCtxState=Clip3(1,127,((m×(QP-32))>>4)+n) (2-10) Where slopeIdx and offsetIdx are limited to 3 bits, and the total initialization value is represented by 6 bits of precision. The probability state preCtxState directly represents the probability in the linear domain. Therefore, preCtxState only requires appropriate shift operations before input to the arithmetic codec engine and saves the logarithmic to linear domain mapping and the 256-byte table. pStateIdx0=preCtxState<<3 (2-11) pStateIdx1=preCtxState<<7 (2-12) 2.2.2 Transform coefficient level encoding and decoding In HEVC, the transform coefficients of a codec block are encoded using non-overlapping coefficient groups (CGs or sub-blocks), and each CG contains the coefficients of a 4x4 block of the codec block. In VVC, the choice of coefficient group size depends only on the TB size, i.e., the dependency on the channel type is removed. As a result, various CGs (1x16, 2x8, 8x2, 2x4, 4x2, and 16x1) become available. The CGs within the codec block and the transform coefficients within the CGs are encoded and decoded according to a predefined scan order. In order to limit the maximum number of context coding binary bits per pixel, the area and color components of the TB are used to derive the maximum number of context coding binary bits for the TB. For luma TBs, the maximum number of context coding binary bits is equal to TB_zosize*1.75. For chroma TBs, the maximum number of context coding binary bits (CCBs) is equal to TB_zosize*1.25. Here, TB_zosize indicates the number of samples within the TB after the coefficients are cleared. Note that the coded_sub_block_flag in the transform skip residual mode is not considered for CCB counting. Unlike HEVC where the residual codec is designed for the signal characteristics at the statistical and transform coefficient levels, two separate residual codec structures are adopted for transform coefficients and transform skip coefficients, respectively. 2.2.2.1 Residual Encoding and Decoding for Transform Coefficients In transform coefficient coding, the variable remBinsPass1 is first set to the maximum number of context coding binary bits and is decremented by one when context coding binary bits are signaled. When remBinsPass1 is greater than or equal to 4, the first coding pass containing sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag is coded using context coding binary bits. If the number of context coding binary bits is not greater than Mcb in the first coding pass, the remainder of the level information indicated as being further coded in the first pass is coded using the syntax element of abs_remainder using Golomb-Rice codes and bypassed coding binary bits. When remBinsPass1 becomes less than 4 when encoding and decoding the first pass, the remaining coefficients indicated to be further encoded and decoded in the first pass are encoded and decoded using the syntax element of abs_remainder, and the coefficients that were not encoded and decoded in the first pass are directly encoded and decoded in the second pass by using Golomb-Rice codes and bypassed encoded binary bits, such as Figure 8. For each TB, remBinsPass1 is reset. The switch from using context-coded binary bits for sig_coeff_flag, abs_level_gt1_flag, par_level_flag, and abs_level_gt3_flag to using bypass-coded binary bits for the remaining coefficients occurs only once per TB at most. For a coefficient subblock, if remBinsPass1 is less than 4, the entire coefficient subblock is coded by using bypass-coded binary bits. After all of the above-mentioned level coding, the sign (sign_flag) is finally bypass-coded for all scan positions with sig_coeff_flag equal to 1. The unified (same) rice parameter (ricePar) derivation is used for both pass 2 and pass 3. The only difference is that baseLevel is set to 4 and 0 for pass 2 and pass 3 respectively. The Rice parameter is determined based only on the sum of the absolute levels of the neighboring five transform coefficients in the local template, but the corresponding base level is also considered as follows: RicePara=RiceParTable[max(min(31,sumAbs,5*baseLevel),0)](2-13). Fig.11 The residual codec structure for a transform block is shown. After termination of the first sub-block codec pass, the absolute value of each of the remaining to-be-coded coefficients is coded by a syntax element dec_abs_level, which corresponds to a modified absolute level value, where a zero level value is conditionally mapped to a non-zero value. On the encoder side, the value of the syntax element dec_abs_level is derived from the absolute level (absLevel), the dependent quantizer state (QState) and the rice parameter (RicePara) as follows: 2.2.2.2 Residual Codec for Transform Skipping Similar to HEVC, VVC supports transform skip mode. Transform skip mode is allowed for luma and chroma blocks. In transform skip mode, the statistical characteristics of the signal are different from those of the transform coefficients, and applying a transform to such residuals in order to achieve energy compression around low-frequency components is generally less effective. Residuals with such characteristics are often found in screen content, as opposed to natural camera-captured content. 2.2.3 Context Modeling for Coefficient Encoding and Decoding The choice of the probability model of the syntax element related to the absolute value of the transform coefficient level depends on the value of the absolute level in the local neighborhood or the absolute level of the partial reconstruction. The template used is Fig.12 Shown in. The chosen probability model depends on the sum of the absolute levels (or partially reconstructed absolute levels) in the local neighborhood and the number of absolute levels greater than 0 in the local neighborhood (given by the number of sig_coeff_flags equal to 1). Context modeling and binarization rely on the following measures for the local neighborhood: -numSig: the number of non-zero levels in the local neighborhood; -sumAbs1: the sum of the absolute levels (absLevel1) of the partial reconstructions after the first pass in the local neighborhood; -sumAbs: the sum of the absolute levels of reconstruction in the local neighborhood; - Diagonal position (d): The sum of the horizontal and vertical coordinates of the current scan position within the transform block. Based on the values ​​of numSig, sumAbs1 and d, the probability model for encoding and decoding sig_flag, par_flag, gt1_flag and gt2_flag is selected. Based on the values ​​of sumAbs and numSig, the Rice parameters for binarizing abs_remainder are selected. In VVC, a reduced 32-point MTS (RMTS32) based on skipping high-frequency coefficients is used to reduce the computational complexity of 32-point DST-7 / DCT-8. Also, all types of zeroing (i.e., RMTS32 and existing zeroing for high-frequency components in DCT2) are considered, accompanied by coefficient codec changes. Specifically, based on the reduced TU size, the binarization of the last non-zero coefficient position codec is encoded and decoded, and the context model selection for the last non-zero coefficient position codec is determined by the original TU size. In addition, 60 context models are used to encode the sig_coeff_flag of the transform coefficients. The selection of the context model index is based on the sum of the maximum values ​​of the absolute levels of the five previous partial reconstructions called locSumAbsPass1, as follows: - If cIdx is equal to 0, ctxInc is derived as follows: ctxInc=12*Max(0,QState-1)+Min((locSumAbsPass1+1)>>1,3)+(d<2?8:(d<5?4:0)) (2-14) --Otherwise (cIdx is greater than 0), ctxInc is derived as follows: ctxInc=36+8*Max(0,QState-1)+Min((locSumAbsPass1+1)>>1,3)+(d<2?4:0)(2-15). 2.2.4 Extended Precision The intermediate precision used in the arithmetic codec engine is increased to include three elements. First, the precision of both probability states is increased to 15 bits compared to 10 bits and 14 bits in VVC. Second, the LPS range update process is modified as follows: if q>=16384 q=2 15 –1–q R LPS =((range*(q>>6))>>9)+1, Where range is a 9-bit variable representing the width of the current interval, q is a 15-bit variable representing the probability state of the current context model, and RLPS is the update range of LPS. This operation can also be implemented by looking up 512x256 entries in a 9-bit lookup table. Third, on the encoder side, the 256-entry lookup table used for bit estimation in VTM is expanded to 512 entries. 2.2.5 Window size based on stripe type Since the statistics are different for different slice types, it is beneficial to have the probability state of the context updated at a rate that is optimal for a given slice type. Therefore, for each context model, three window sizes are predefined for I slices, B slices, and P slices, respectively, as initialization parameters. Retrain the context initialization parameters and window size. 2.2.6 Temporal CABAC The use of previous codec slices for CABAC initialization in JEM was proposed in JVET-K0379 and studied in VVC CE5. Specifically, if the current slice type is B or P, after the CTU is encoded and decoded to the specified location and stored, the probability state of each context model is first obtained. Then, the stored probability state will be used as the initial probability state of the corresponding context model in the next B slice or P slice encoded and decoded with the same quantization parameter (QP). 2.3 Adaptive Reordering of Merge Candidates with Template Matching (ARMC) The merge candidates are adaptively reordered using template matching (TM). The reordering method is applied to the normal merge mode, template matching (TM) merge mode and affine merge mode (excluding SbTMVP candidates). For the TM merge mode, the merge candidates are reordered before the refinement process. After constructing the merge candidate list, the merge candidates are divided into several subgroups. For the normal merge mode and the TM merge mode, the subgroup size is set to 5. For the affine merge mode, the subgroup size is set to 3. The merge candidates in each subgroup are sorted in ascending order according to the cost value based on template matching. For simplicity, the merge candidates in the last subgroup instead of the first subgroup are not reordered. The template matching cost of the merge candidate is measured by the sum of absolute differences (SAD) between the samples of the template of the current block and its corresponding reference samples. The template includes a set of reconstructed samples adjacent to the current block. The reference samples of the template are located by the motion information of the merge candidate. When the merge candidate uses bidirectional prediction, the reference sample of the merge candidate template is also composed of Fig.13 The bidirectional prediction shown in is generated. For a sub-block based merge candidate with a sub-block size equal to Wsub×Hsub, the upper template includes several sub-templates of size Wsub×1, and the left template includes several sub-templates of size 1×Hsub. Fig.14 As shown, the motion information of the sub-blocks in the first row and the first column of the current block is used to derive the reference samples of each sub-template. 3. Question There are several problems with existing video codec technologies, which will be further improved for higher codec gain. 1. The CABAC initialization probability of inter slices can be inherited from the stored probability of previously coded slices (eg, temporal CABAC). However, how to derive the context initialization probability from temporal information needs to be designed, especially when a temporal picture contains more than one slice. 2. In ECM-4.0, sign prediction is used to estimate the sign (+ or -), but not for IBC AMVP. Symbols of IBC MVD can be predictively encoded and decoded. 3. In VVC and ECM, when the IBC predictor pointed to by a motion vector candidate is not in the valid region, the motion vector candidate is considered invalid. However, in this case, a new motion vector candidate can be inserted into the IBC motion list based on the invalid IBC motion candidate. 4. Currently in ECM-4.0, intra template matching is only applied to luma components. For chroma, if it is signaled as DM mode, the chroma mode is set to planar mode (without reusing the concept of intra template matching). However, for extensions of intra template matching (e.g., if sample reordering-based intra template matching is enabled), it is possible to further define how to handle chroma block codecs. 5. For the motion list construction considering sample ordering, more technical details can be defined. a. Whether and how to consider the rollover type of neighboring blocks and the current block for IBC AMVP list construction. b. Whether and how to consider the flipping type of neighboring blocks and the current block for motion candidate reordering / sorting (eg, ARMC). c. New motion candidates can be generated based on sample reordering. 6. In ECM-5.0, intra TM is only used for luma blocks for both single-tree and dual-tree cases, and if a block is coded by intra template matching (intra TM), the block will be considered as coded INTRA_PLANAR mode for the following block, which may not be efficient. 7. In ECM-5.0, if a block is coded by IBC mode, it is not used for future intra-mode coded blocks, which may not be efficient. 8. In ECM-5.0, most of the codec tools used for natural sequence coding can also be applied to screen content coding, which may not be efficient. 4. Detailed solution The following detailed embodiments should be considered as examples to explain the general concept. These embodiments should not be interpreted in a narrow sense. In addition, these embodiments 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 CABAC initialization probability (e.g., the first problem and related problems), the following method is proposed: a. It may be required that the context initialization probability of the first slice does not depend on the context initialization probability obtained from the second slice in the same picture (eg, in the case where more than one slice is contained in each picture of the video sequence). a. For example, the second slice is encoded and decoded before the first slice. b. It may be required that the context initialization probability of the first slice does not depend on the context initialization probability obtained from the second slice in a different picture. c. The context initialization probability of the first slice in the first picture may depend on the context initialization probability obtained from the second slice in the second picture. a. For example, the first picture is different from the second picture. b. For example, the second picture is encoded and decoded before the first picture. c. For example, the second picture may be a reference picture of the first slice / picture. d. For example, the second picture is not necessarily a reference picture of the first slice / picture. d. The initialization probability dependency of the first and second stripes can be based on the stripe type but not the quantization parameter (QP). a. For example, when the first slice and the second slice are coded with the same slice type X (eg, X=B or P slice), the context initialization probability of the first slice may depend on the context initialization probability of the second slice. b. For example, the context initialization probability of the first slice may depend on the context initialization probability of the second slice, regardless of the QP values ​​used for the first slice and the second slice. e. The context initialization probability of the first slice may depend on the context initialization probability obtained from the second slice based on the quantization parameter (QP). a. For example, how the first slice derives the context initialization probability from the second slice may be based on whether the first slice and the second slice have the same / similar QP value (eg, whether the QP difference is less than a threshold). b. For example, how the first slice derives the context initialization probability from the second slice may be based on whether the first slice and the second slice are from the same QP range (eg, the QP range may be defined by a predefined rule). c. For example, how the first slice derives the context initialization probability from the second slice may be based on whether the first slice and the second slice are from the same QP class (eg, the QP class may be defined by a predefined rule). f. In the case where the first slice derives the context initialization probability from the second slice, it may be required that the temporal layer of the second slice is not larger than the temporal layer of the first slice. a. For example, in the case where the first slice derives the context initialization probability from the second slice, the temporal layer of the second slice may be smaller than the temporal layer of the first slice. b. For example, in the case where the first slice derives the context initialization probability from the second slice, the temporal layer of the second slice may be equal to the temporal layer of the first slice. c. For example, in the case where the first slice derives the context initialization probability from the second slice, the temporal layer of the second slice should not be larger than the temporal layer of the first slice. g. In one example, the context initialization probability of the first slice may depend on the context initialization probability obtained from the second slice, and an indication of the second slice may be signaled in the first slice. h. In one example, the context initialization probability of the first slice may depend on the context initialization probability obtained from the second slice, and the second slice must be a reference slice for the first slice. 4.2 Regarding the sign prediction of block vector differences (e.g., the second problem and related problems), the following method is proposed: a. IBC Codec The sign of the horizontal component and / or the vertical component of the block vector difference (eg, BVD, MVD) of a video unit may be predictively coded. b. The sign of the block vector difference (eg, BVD, MVD) component of an IBC-coded video unit may be represented by an index from a lookup table. a. For example, symbol candidates in a lookup table may be predefined and used for both the encoder and the decoder. b. For example, symbol candidates in a lookup table can be generated on the fly. c. For example, at least two symbol lookup tables may be allowed to be used for encoding and decoding IBC block vector differences. i. For example, the symbol lookup table is on a per-block basis. ii. For example, the order of the symbol candidates in the first symbol lookup table and the order of the symbol candidates in the second symbol lookup table may be different. d. For example, the symbol candidates in the lookup table may be generated based on the cost / error / difference obtained from the template matching method. i. For example, the symbol candidates in the lookup table may be reordered based on a template matching method. ii. For example, template matching may refer to matching a first predefined group of reconstructed samples neighboring a first block (eg, a current block) and a second predefined group of reconstructed samples neighboring a second block (eg, a reference block to the current block). e. For example, the index of the sign of the block vector difference (eg, BVD, MVD) component of the IBC coded video unit may be context coded. 4.3 Regarding block vectors outside the invalid region (e.g., the third problem and related problems), the following method is proposed: a. If a block vector candidate of an IBC codec block is outside the reference region, the block vector may be changed to another value instead of being discarded from the IBC candidate list. a. For example, an operation may be applied to a block vector and change it to a valid block vector within a reference region. i. For example, the operation can be based on a clipping process. ii. For example, the operation may be based on a scaling process. b. For example, a clipping operation may be applied to a block vector to clip it within a reference region. i. For example, you can clip to the nearest boundary of the reference region, such as Fig.13 shown. c. For example, an invalid block vector may be replaced with a new block vector. 4.4 Regarding sample ordering of chroma block coding and decoding (e.g., the fourth problem and related problems), the following method is proposed: a. For example, when intra template matching is used, the luma block and chroma block of a video unit may share the same block vector. i. For example, if intra template matching is applied to a luma block, then the associated chroma block can derive a chroma prediction based on the block vector calculated from the luma block. b. For example, the luma blocks and chroma blocks of a video unit may share the same sample reordering method (eg, no flip, horizontal flip, vertical flip, etc.). i. For example, if a sample reordering method is applied to a luma block, then the associated chroma block may perform the same sample reordering method as the luma block. ii. For example, luma blocks can be encoded and decoded as sample reordering based on intra template matching. b. For example, assuming that the luma component is encoded based on a specific encoding method, sample reordering (eg, horizontal flipping, vertical flipping, etc.) may be applied only to the luma component. i. For example, a specific coding method may be based on intra-frame template matching. c. For example, when the luminance block is encoded and decoded using the sample reordering method, the chrominance block may be encoded and decoded using a prediction method different from the prediction method of the luminance block. i. For example, a chroma intra-frame mode (e.g., DM mode, planar mode, DC mode, CCLM mode, etc.) may be used to encode and decode a chroma block, while a sample reordering method (e.g., no flip, horizontal flip, vertical flip, etc.) may be used to encode and decode a luminance block. ii. For example, a chroma intra-frame mode (eg, DM mode, planar mode, DC mode, CCLM mode, etc.) may be used to encode the chroma block, while the luminance block may be encoded and decoded using intra-frame template matching based on sample reordering. d. For example, the claimed rules may depend on whether a dual tree (and / or a partial dual tree) is applied. i. Alternatively, the claimed rules may be applied regardless of whether dual trees (and / or local dual trees) are applied. 4.5 Regarding the construction of motion lists considering sample ordering (e.g., the fifth problem and related problems), the following method is proposed: Assume that the first block is a neighboring block that was encoded and decoded before the current block, and the target block is the current block being encoded and decoded: a. Considering the reordering method (e.g., no flip, horizontal flip, vertical flip, etc.), a motion list can be generated. i. In one example, a reordering method that examines the first block (eg, an already encoded neighboring block) may be used for motion list generation. ii. In one example, a reordering method of a target block (eg, a current block being encoded and decoded) may be checked for motion list generation. iii. In one example, as long as the first block (eg, neighboring block) is encoded and decoded using a sample reordering method, the motion list construction for the target block can be adjusted (eg, by adding a motion shift or delta MV) for the motion derived from the first block. iv. In one example, as long as the target block (eg, current block) is encoded and decoded using a sample reordering method, the motion list construction for the target block may be adjusted (eg, by adding a motion shift or delta MV) to the motion derived from the first block. v. In one example, as long as the reordering method of the first block (e.g., the neighboring block) and the reordering method of the target block (e.g., the current block) are the same (e.g., both are encoded and decoded without sample reordering or horizontal flipping or vertical flipping, etc.), 1. For example, the motion of the first block (and / or its variants) may be inserted into the motion list of the target block. 2. For example, the motion list construction for the target block may adjust (eg, by adding a motion shift or delta MV) the motion derived from the first block. b. The motion candidate index ordering (eg, ARMC) may depend on the sample reordering method used for neighboring blocks and / or the sample reordering method used for the target block (eg, current block). i. For example, motion candidates may be grouped depending on the sample reordering method (eg, no flipping, horizontal flipping, vertical flipping, etc.). 1. For example, the motion candidates derived from the sample reordered coded neighboring blocks may be placed at the front of the motion list. a. Alternatively, those motion candidates may be placed at the end of the motion list. 2. For example, motion candidates derived from non-sample reordering coded neighboring video units may be placed after motion candidates derived from sample reordering coded neighboring blocks. a. Alternatively, those motion candidates may be placed before the motion candidates derived from the sample reordering codec neighboring blocks. ii. For example, motion candidates derived from neighboring blocks encoded using a first codec method are considered as a first group (e.g., ARMC) for index sorting, while motion candidates derived from neighboring blocks encoded using a second codec method can be considered as a second group (e.g., ARMC) for candidate index sorting. 1. For example, the first coding method may refer to all kinds of sample reordering methods (eg, any type of horizontal flipping, vertical flipping, etc.). a. Alternatively, the first encoding and decoding method may refer to a specific type of sample reordering method (For example, flip horizontally or vertically, etc.). b. Alternatively, the first coding method may refer to the same sample reordering method as the current / target block. 2. For example, the second encoding and decoding method may refer to a non-sample reordering method. a. Alternatively, the second encoding and decoding method may refer to a specific type of sample reordering method (eg, vertical flipping or horizontal flipping, etc.). 3. For example, motion candidates derived from neighboring blocks encoded and decoded using the same sample reordering method can be considered as one group for candidate index ordering (eg, ARMC). 4. For example, only motion candidates derived from neighboring blocks encoded using a sample reordering method may be applicable to candidate index ordering (eg, ARMC). 5. For example, only motion candidates derived from neighboring blocks encoded and decoded using a specific type of sample reordering method (eg, horizontal flip or vertical flip, etc.) may be applicable to the candidate index ordering (eg, ARMC). 6. For example, only motion candidates derived from neighboring blocks encoded using non-sample reordering methods may be suitable for candidate index ordering (eg, ARMC). 7. For example, only when motion candidates are derived from neighboring blocks that are encoded and decoded using the same sample reordering method as the target block, those motion candidates can be ordered (eg, ARMC). c. At least one new motion candidate may be added to the motion list. i. For example, considering the re-ordering method, new motion candidates can be generated based on motion adjustment (eg, by adding motion offset or delta MV). ii. For example, it may be necessary for the new motion candidate to have the same reordering method as the target block (e.g., No reordering, horizontal flipping, vertical flipping, etc.). 1. Alternatively, the new motion candidate does not necessarily have the same reordering method as the target block (e.g. No reordering, horizontal flipping, vertical flipping, etc.). iii. For example, new motion candidates may be generated based on the motion of adjacent neighboring blocks. iv. For example, new motion candidates may be generated based on the motion of non-adjacent neighboring blocks. v. For example, new motion candidates may be generated based on motion from a specific buffer (lookup table, HMVP table, etc.). vi. For example, when the motion list is not complete (the length of the motion list is less than a predefined value), the claimed rules may be used. d. In one example, the claimed motion list may be a block / motion vector list of an IBC codec block. i. For example, it can be IBC AMVP coded. ii. For example, it can be IBC combined codec. iii. Alternatively, motion lists may be used for codec modes other than IBC. e. For example, the claimed rules may be used in case the first block is encoded and decoded using a sample reordering method. i. Alternatively, the claimed rules may be used without encoding or decoding the first block with sample reordering. ii. Alternatively, the claimed rules may be used regardless of the sample reordering method of the first block. f. For example, the claimed rules may be used when encoding a target block using a sample reordering method. i. Alternatively, the claimed rules may be used without encoding or decoding the target block with sample reordering. ii. Alternatively, the claimed rules may be used regardless of the sample reordering method of the target block. g. For example, the claimed rules may be used in the case where the target block is encoded and decoded using IBC AMVP (and / or its variants). i. Alternatively, the claimed rules may be used when encoding or decoding the target block in an AMVP mode other than IBC AMVP. h. For example, the claimed rules may be used in case the target block is a codec IBC merge (and / or its variants). i. Alternatively, the claimed rules may be used when the target block is encoded and decoded in a merge mode other than IBC merge. 4.6 Regarding the use of intra-frame TM codec and its codec information (e.g., the sixth question and related questions), the following method is proposed: a. In one example, the generated intra mode may be generated based on the codec information of the reference block of the intra TM codec block. a. For example, the reference block can be derived based on the block vector of the intra TM coded block. b. For example, the generated intra mode of the intra TM codec block may be derived based on one or more of the following: i. Intra mode of the reference block (eg, intra mode index, intra mode angle, etc.). ii. Gradient of the reference patch. iii. Prediction mode(s) of the reference block. iv. The coding information of the reference block covered by the CU (e.g., prediction mode, intra mode index, Intra mode angle, etc.). c. For example, if the CU covering the reference block contains multiple candidate blocks, one intra mode among those multiple intra modes may be selected for the generated intra mode. i. For example, the selected rule may be based on the prediction mode of the candidate block (eg, whether it is intra mode and / or intra TM and / or IBC prediction). ii. For example, the selected rule may be based on a predefined candidate block checking order. iii. For example, the selection rule may be based on the position of the candidate block relative to the intra TM block. iv. For example, the selection criteria may be based on template cost. d. For example, if the reference block (and / or the CU covering the reference block) is not coded by intra and / or IBC and / or intra TM modes, the PLANAR mode may be used as the generated intra mode. b. In one example, the generated intra mode may be generated based on the codec information of the intra TM codec block. a. For example, the generated intra mode may be derived based on the block vector of the intra TM coded block. i. For example, the direction of the block vector can be utilized. ii. For example, based on the direction / angle of the block vector, a generated / converted / mapped intra mode may be generated and stored as the intra mode of the intra TM codec block. b. For example, the generated intra-mode may be derived based on a mapping table. i. For example, the mapping table may contain at least one entry based on a block vector of an intra TM coded block. c. For example, the generated intra mode may be derived based on the gradient of the intra TM codec block. i. For example, based on the gradient, a generated / converted / mapped intra mode may be generated and stored as an intra mode of an intra TM codec block. c. In one example, the generated intra-mode of the intra TM block may be stored in a buffer. a. For example, the prediction block of the intra TM block is not generated based on the generated intra mode. b. For example, the stored intra mode of an intra TM block can be used for encoding and decoding of a subsequent block. d. In one example, the generated intra mode of the intra TM codec block may be used for the codec of the following block, wherein the codec of the following block includes one or more processes as follows: a.MPM list generation i. For example, the MPM list for regular intra mode ii. For example, MPM list for GPM intra-frame inter-frame mode iii. For example, MPM list for spatial GPM intra mode iv. For example, MPM list for MIP mode v. For example, the MPM list for TIMD mode vi. For example, any first MPM list for video codec vii. For example, any second MPM list for video codec b.TIMD mode / prediction export c. DIMD-based pattern / prediction derivation d. Fusion-based model / prediction derivation e. Deblocking filter i. For example, deblocking strength (eg, long filter, short filter, strong filter, weak filter, etc.). ii. For example, filter strength of the deblocking process (eg, derivation of bS values). e. In one example, the intra TM based prediction block may be fused with the second prediction block. a. For example, it can be fused with DIMD prediction. b. For example, it can be fused with TIMD prediction. c. For example, it can be fused with MHP prediction. d. For example, it can be fused with IBC prediction. f. In one example, the block vector of the intra-frame TM codec block can be used for the codec of the next block, where The encoding and decoding of the latter block includes one or more of the following processes: a. IBC prediction list generation i. For example, AMVP / MERGE list for regular IBC mode ii. For example, AMVP / MERGE list for IBC-TM mode iii. For example, AMVP / MERGE list for IBC-MMVD mode iv. For example, AMVP / MERGE list for RRIBC mode b. TIMD-based model / prediction derivation c. DIMD-based pattern / prediction derivation g. In one example, intra TM can be used for chroma blocks (single tree and / or dual tree). a. For example, in a single tree, the block vectors of the chroma intra TM can be derived based on the block vectors of the corresponding luma intra TM. b. For example, in a single tree, if the chroma block is coded as INTRA_DM mode and the luma block is coded as intra TM mode, the chroma block can be coded as intra TM mode based on the block vector of the corresponding luma. c. For example, in a single tree, the chroma intra TM can share the same intra frame with the luma intra TM TM syntax (e.g., flags used by intra-frame TM). d. For example, in a single tree, searching for a block vector for an intra TM coded block may consider costs from both luma and chroma. e. For example, in a dual tree, the block vector of the chroma intra TM can be based on the corresponding luma intra TM The block vectors (without searching) are derived. f. For example, in a dual tree, the intra TM flag of a chroma block may be inherited from the corresponding luma block (without signaling). g. For example, in a dual tree, if the chroma block is coded as INTRA_DM mode and the luma block is coded as intra TM mode, the chroma block may be coded as intra TM mode. 4.7. Regarding the IBC codec mode for future intra-mode codecs (e.g., Issue 7 and related issues), the following method is proposed: a. For example, the generated intra-mode may be generated for an IBC codec block and used for intra-mode codec / prediction of a subsequent / future block. b. In one example, the generated intra mode may be generated based on the codec information of the reference block of the IBC codec block. a. For example, the reference block can be derived based on the block vector of the IBC codec block. b. For example, the generated intra-mode of the IBC codec block may be derived based on one or more of the following: i. Intra mode of the reference block (eg, intra mode index, intra mode angle, etc.). ii. Gradient of the reference patch. iii. Prediction mode(s) of the reference block. iv. Codec information of the CU covering the reference block (e.g., prediction mode, intra mode index, intra mode angle, etc.). c. For example, if the CU covering the reference block contains multiple candidate blocks, one intra mode among those multiple intra modes may be selected for the generated intra mode. i. For example, the selected rule may be based on the prediction mode of the candidate block (eg, whether it is intra mode and / or intra TM and / or IBC prediction). ii. For example, the selected rule may be based on a predefined candidate block checking order. iii. For example, the selection rule may be based on the position of the candidate block relative to the IBC block. iv. For example, the selection criteria may be based on template cost. d. For example, if the reference block (and / or the CU covering the reference block) is not coded by intra and / or IBC and / or intra TM mode, then PLAAR mode may be used as the generated intra mode. c. In one example, the generated intra mode may be generated based on the codec information of the IBC codec block. a. For example, the generated intra-mode may be derived based on the block vector of the IBC codec block. i. For example, the direction of the block vector can be utilized. ii. For example, based on the direction / angle of the block vector, a generated / converted / mapped intra-mode may be generated and stored as the intra-mode of the IBC codec block. b. For example, the generated intra-mode may be derived based on a mapping table. i. For example, the mapping table may contain at least one entry based on a block vector of an IBC codec block. c. For example, the generated intra-mode may be derived based on a gradient of an IBC codec block. i. For example, based on the gradient, a generated / converted / mapped intra-mode may be generated and stored as an intra-mode of an IBC codec block. d. In one example, the generated intra-mode of the IBC block may be stored in a buffer. a. For example, the prediction block of the IBC block is not generated based on the generated intra mode. b. For example, the stored intra-mode of an IBC block can be used for encoding and decoding of a subsequent block. e. In one example, the generated intra-frame mode of the IBC codec block can be used for the codec of the following block, where the codec of the following block includes one or more of the following processes: a.MPM list generation i. For example, the MPM list for regular intra mode ii. For example, MPM list for GPM intra-frame inter-frame mode iii. For example, MPM list for spatial GPM intra mode iv. For example, MPM list for MIP mode v. For example, the MPM list for TIMD mode vi. For example, any first MPM list for video codec vii. For example, any second MPM list for video codec b.TIMD mode / prediction export c. DIMD-based pattern / prediction derivation d. Fusion-based model / prediction derivation e. Deblocking filter i. For example, deblocking strength (eg, long filter, short filter, strong filter, weak filter, etc.). ii. For example, filter strength of the deblocking process (eg, derivation of bS values). f. In one example, the IBC-based prediction block may be fused with the second prediction block. a. For example, it can be fused with DIMD prediction. b. For example, it can be fused with TIMD prediction. c. For example, it can be fused with MHP prediction. d. For example, it can be fused with intra TM prediction. 4.8 Regarding screen content encoding and decoding (e.g., Question 8 and related questions), the following method is proposed: g. For example, one or more codec tools from the following may be disabled for screen content codecs. a. DIMD and / or its variants b. TIMD and / or its variants c. OBMC and / or its variants d. LIC and / or its variants e. MHP and / or its variants f. CIIP and / or its variants g. Fusion / mixing process of two predictions h. Deblocking and / or its variants i.ALF and / or its variants j. SCC and / or its variants k. Bilateral filter and / or its variants h. For example, a high-level syntax (higher than block-level syntax) may be signaled at the SPS / PPS / PH / SH level to indicate whether specific tools are disabled for screen content codec. General Requirements 4.9 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. 4.10 Whether and / or how to apply the above disclosed methods may be signaled in a PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / tile / sub-picture / other kind of region containing more than one sample or pixel. 4.11 Whether and / or how to apply the above disclosed method may depend on codec information, such as block size, color format, single tree / dual tree partitioning, color component, slice / picture type. 5 Previous Solutions 5.1 About sample reordering - motion list generation, implicit export and how to reorder_v1 The following detailed embodiments should be considered as examples to explain the general concept. These embodiments should not be interpreted in a narrow sense. In addition, these embodiments 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. 5.1.1 Regarding motion candidate list generation for sample reordering (e.g., the first problem and related problems), the following method is proposed: a. For example, the IBC merge motion candidate list can be used for both regular IBC merge mode and sample-based reordering Sequential IBC merge mode. b. For example, the IBC amvp motion predictor candidate list can be used for both the regular IBC amvp mode and the Sample reordering for IBC amvp mode both. c. For example, a new motion (pre- Test) candidate list. a. For example, the new candidate list may only consider motion candidates having 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 with sample reordering (but regardless of the type of sample reordering method) may be inserted. ii. For example, non-adjacent candidates having the same reordering method as that of the target video unit may be inserted. iii. For example, whether or not a sample reordering method is used for the candidates, non-adjacent candidates may be inserted. e. For example, new motion candidates may be generated according to specific rules and inserted into the new candidate list. i. For example, the rules can be based on an averaging process. ii. For example, rules can be based on a tailoring process. iii. For example, the rules can be based on a scaling process. d. For example, the motion (predictor) candidate list generation for the target video unit may rely on a re-ordering method. a. For example, the reordering method associated with each motion candidate (from the spatial or temporal or history table) may be inserted into the list, regardless of whether the target video unit is coded with sample reordering or not. b. For example, if the target video unit is to be encoded using sample reordering, only those motion candidates (from the spatial or temporal or history table) that are encoded using 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 or temporal or history table) that are coded with sample reordering are inserted into the list. d. For example, if the target video unit is encoded without sample reordering, those motion candidates (from the spatial or temporal or history table) that are encoded with the same reordering method may not be inserted into the list. e. Alternatively, motion list generation for a video unit may not rely on a reordering method associated with each motion candidate. e. For example, adaptive reordering of merge candidates of video units (ARMC) may rely on a reordering method. a. For example, if the target video unit is to be encoded and decoded using sample reordering, motion candidates encoded and decoded using the same reordering method as the target video unit may be placed before those motion candidates encoded and decoded using a different reordering method. b. For example, if the target video unit is to be encoded using sample reordering, motion candidates encoded using sample reordering (but regardless of the type of sample reordering method) can be placed before those motion candidates encoded using a different reordering method. c. For example, if the target video unit is encoded without sample reordering, the motion candidates encoded without the reordering method may be placed before those motion candidates encoded with the reordering method. d. Alternatively, ARMC may be applied to video units regardless of the reordering method associated with each motion candidate. f. For example, an IBC merge candidate list may be constructed, allowing the candidates to be encoded or decoded with or without sample reordering. a. For example, depending on whether the spatial / temporal block is coded with or without sample reordering, determining whether the candidates from the spatial / temporal block have or do not have sample reordering. b. For example, depending on whether the block corresponding to the history table entry is coded with or without sample reordering, determining whether the candidate from the history table entry has or does not have sample reordering. c. For example, depending on whether the selected IBC merge candidate is coded with or without sample reordering, determining whether the current block has or does not have sample reordering. 5.1.2 Regarding the implicit determination of sample reordering (e.g., the second problem and related problems), the following method is proposed: a. Whether the reconstructed / original / predicted samples of the reordered video units 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 from codec information. i. For example, the cost / error / difference may 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 adjacent to a current video unit, and a second template is constructed from a set of corresponding samples adjacent to a reference video unit. 2. For example, the cost / error may refer to the cumulative sum of the differences between samples in the first template and corresponding samples in the second template. a. For example, the difference may be based on 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) may be calculated without reordering, and the second cost (represented by Cost1) may be calculated with reordering. 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, it may be signaled in the bitstream whether to reorder the reconstructed / original / predicted samples of a video unit. i. For example, it can be signaled by a syntax element (eg, a flag). b. Which reordering method to use 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 the cost / error / difference calculated from the codec information. i. For example, the cost / error / difference may 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 adjacent to a current video unit, and a second template is constructed from a set of corresponding samples adjacent to a reference video unit. 2. For example, the cost / error may refer to the cumulative sum of the differences between samples in the first template and 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 (represented by Cost0) may not be calculated using reordering method A, and the second cost (represented by Cost1) may be calculated using reordering method B. Finally, the minimum cost value in {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 or an index or a parameter or a variable). c. Whether and which reordering method is used 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. For example, the first cost (represented by Cost0) may be calculated without reordering, the second cost (represented by Cost1) may be calculated using reordering method A, and the third cost (represented by Cost2) may be calculated using reordering method B. Finally, the minimum cost value among {Cost0, Cost1, Cost2} is identified, and the corresponding codec method (no reordering, reordering method A, reordering method B) is determined as the final codec method of the video unit. 5.1.3 Regarding how to reorder samples (e.g., the third question and related questions), the following method is proposed: a. A possible sample reordering method may 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 based on tiles / slices / pictures. b. Samples of a video unit may be transformed according to an M parameter model (eg, M=2 or 4 or 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. 5.1.4 Regarding motion vector adjustment for sample reordering (e.g., the fourth question and related questions), the following method is proposed: a. Assuming that a first motion vector is obtained for a sample reordering codec video unit (eg, a current block) based on codec information of neighboring blocks, a second motion vector may be generated to refine / adjust the first motion vector. a. For example, a motion vector candidate for the IBC merge mode may be obtained based on the second motion vector. b. For example, a motion vector predictor for IBC AMVP mode may be obtained based on the second motion vector. c. For example, how to generate the second motion vector may be based on the prediction method of the current block (eg, whether the video unit is encoded or decoded by the MERGE mode or the AMVP mode). d. For example, the second motion vector may be generated based on the block size (such as block width and / or height) of the current block. e. For example, the second motion vector may be generated based on a fixed / predefined number (eg, 4 or 8, which may be the granularity of the spatial motion vector storage unit). f. For example, the second motion vector may be generated based on a reordering method of the current block and the neighboring blocks (eg, a reordering method, such as no reordering, horizontal flipping, or vertical flipping). i. In one example, assuming that the current block is undergoing IBC AMVP with horizontal flipping, the motion vectors of neighboring blocks that are decoded with horizontal flipping may be refined / adjusted to construct a motion vector predictor list. 1. Additionally, alternatively, the motion vectors of the neighboring blocks of the vertical flip and / or no-reordering codec may not be refined / adjusted for constructing the motion vector predictor list. ii. In one example, assuming that the current block is undergoing IBC AMVP with vertical flipping, the motion vectors of the neighboring blocks that are decoded with vertical flipping may be refined / adjusted for constructing the motion vector predictor list. 1. In addition, the motion vectors of neighboring blocks of horizontal flipping and / or no-reordering coding may not be refined / adjusted for constructing the motion vector predictor list. g. For example, the second motion vector may be generated based on the coding information of the neighboring blocks. h. For example, the neighboring block may be adjacent to the current block at the left, lower left, above, upper right, or upper left. i. For example, the second motion vector may be generated based on the prediction mode of the neighboring block (eg, whether it is coded by MODE_IBC). j. For example, the second motion vector may be generated based on the block size (such as block width and / or height) of the neighboring block. k. For example, the second motion vector may be generated based on a reordering method of neighboring blocks (eg, a reordering method, such as no reordering, horizontal flipping, or vertical flipping). 1. For example, the second motion vector may be generated based on the position of the neighboring block relative to the current block (eg, left side, bottom left, top, top right, or top left neighboring the current block). m. For example, the second motion vector may be generated based on the coordinates of the position of the current block or a neighboring block (such as a center point or an upper left point). n. For example, the second motion vector may be generated based on adding a shift factor to the first motion vector. i. For example, the shift factor may have the same precision as the first motion vector. ii. For example, the shift factor may be generated based on the block size (such as block width and / or height) of the current block. iii. For example, the shifting factor may be generated based on a fixed / predetermined number, such as 4 or 8 or 2, which may be the granularity of the spatial motion vector storage unit. o. For example, the second motion vector may be different from the first motion vector. p. For example, in Fig.15 An example of current motion vector (block vector) adjustment is shown in W1 represents the width of the current block, W2 represents the width of the left neighboring block of the current block, leftMV represents the motion vector (block vector) of the left neighboring block, and curMV represents the motion vector (block vector) of the current block. Therefore, for example, as shown in the figure, the left neighboring block is encoded and decoded using horizontal flipping, instead of directly inheriting the leftMV of curMV, the horizontal component of curMV can be calculated as curMVx=leftMVx-(W2< <precFactor)-(W1<<precFactor)。 i. For example, precFactor may be a value based on the precision difference between MV / BV precision and integer precision (such as 0 or 4 or 6). ii. For example, W2 may be equal to a value (eg, W2=4 or 2 or 8, which may be the granularity of the spatial motion vector storage unit). iii. In addition, the left neighboring block may be a previously coded block on the left side (adjacent or non-adjacent) of the current block. iv. In addition, the left neighboring block may be located at the lower left side of the current block. q. For example, the current motion vector (block vector) adjustment example is Fig.17 As shown in the figure, H1 H2 represents the height of the current block, H3 represents the height of the upper neighboring block of the current block, aboveMV represents the motion vector (block vector) of the upper neighboring block, and curMV represents the motion vector (block vector) of the current block. Therefore, when the upper neighboring block is encoded and decoded with vertical flipping as shown in the figure, instead of directly inheriting curMV from aboveMV, the vertical component of curMV can be calculated as curMVy=aboveMVy-(H2< <precFactor)–(H1<<precFactor)。 i. For example, precFactor may be a value based on the precision difference between MV / BV precision and integer precision (such as 0 or 4 or 6). ii. For example, H2 may be equal to a value (such as H2=4 or 2 or 8, which may be the granularity of the spatial motion vector storage unit). iii. In addition, the upper neighboring block may be a previously coded block above (adjacent or non-adjacent) the current block. iv. In addition, the upper neighboring block may be located on the upper right side of the current block. b. Assuming that a first motion vector is obtained for a sample reordering codec video unit (e.g., a current block) based on codec information of neighboring blocks, a second motion vector may be generated to refine / adjust the first motion vector. Whether to adjust / refine the first motion vector to the second motion vector may depend on whether the assumed motion vector satisfies certain rules. a. For example, if at least one rule is not satisfied, the hypothesized second motion vector may not be used. i. For example, the second motion vector may be discarded. ii. For example, both the first motion vector and the second motion vector may be discarded. iii. For example, the first motion vector without adjustment / refinement may be used. iv. For example, the second motion vector may be set equal to the first motion vector. b. For example, if all rules are satisfied, the hypothesized second motion vector may be used as the second motion vector. c. For example, a rule may include at least one of the following: i. The reference block pointed to by the assumed motion vector is within the valid area (where the valid area may be a predefined previously encoded area). ii. The reference block pointed to by the assumed second motion vector is within the current picture. iii. The reference block pointed to by the assumed second motion vector is in the same CTU row of the video unit. iv. The reference block pointed to by the hypothetical second motion vector is in the same picture block of the video unit. v. The reference block pointed to by the assumed second motion vector is in the same CTU or to the left of the video unit In CTU. vi. The reference block pointed to by the assumed motion vector is within the already coded area. c. For example, two examples of current motion vector (block vector) adjustment are Fig.18 and Fig.19 As shown in , (x1, y1) and (x2, y2) represent the coordinates of the center points of the neighboring block and the current block, respectively, (W1, H1) and (W2, H2) represent the width and height of the left neighboring block and the current block, BV represents the motion vector (block vector) of the left neighboring block, BV' represents the motion vector (block vector) of the current block, and (x'1, y'1) and (x'2, y'2) represent the coordinates of the upper left point of the neighboring block and the current block, respectively. a. For example, (x1, y1) and (x2, y2) can be derived as 1. x1=x'1+W1 / 2+sx and y1=y'1+H1 / 2+sy. 2. x2=x'2+W2 / 2+sx and y2=y'2+W1 / 2+sy. Where sx and sy are offsets, such as 0, 1, -1. b. The MV (BV) adjustment / refinement method may depend on how the sample reordering is performed. i. In one example, for horizontal flipping, BV' x =2(x1-x2)+BV x and / or BV' y = BV y ,like Fig.18 shown. ii. In one example, for vertical flipping, such as Fig.19 As shown, BV' y =2(y1-y2)+BV y and / or BV' x =BV x . c. In addition, BV can have integer precision. d. In addition, BV can indicate the fractional precision domain MV, so, i. In one example, for horizontal flip, MV' x =((2(x1-x2))< <precFactor)+MV x ii. In one example, for vertical flip, MV' y =((2(y1-y2))< <precFactor)+MVy Here, preFactor may be a value (eg, 0, 4, or 6) based on the precision difference between the MV precision and the integer precision. d. In one example, the neighboring blocks disclosed in the document may be adjacent to the current block or not adjacent to the current block. e. In one example, the information of neighboring blocks disclosed in the document can be stored in a table (such as a table based on history). Historical motion vector prediction, HMVP table), and information can be obtained from the table to perform MV adjustment. a. For example, this information may include: i. Motion information (MV and / or BV and / or reference picture and / or inter prediction). ii. Center point coordinates. iii. Coordinates of the upper left point. iv. Width and / or Height. v. Sample reordering type (such as no reordering, vertical flip and / or horizontal flip). f. The refined / adjusted MV / BV can be clipped to the range. General Requirements 5.1.5 Whether and / or how to apply the above disclosed methods can be applied at the sequence level / picture group level / picture level / Signaled at slice level / tile group level, for example in sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / tile group header. 5.1.6 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 kind of area containing more than one sample or pixel. 5.1.7 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 components, slice / picture type. 5.2 About motion constraints, AMVR signaling, template matching and sample reordering_v1 The following detailed embodiments should be considered as examples to explain the general concept. These embodiments should not be interpreted in a narrow sense. In addition, these embodiments 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. 5.2.1 Regarding motion constraints for codec tools (e.g., the first problem and related problems), the following approach is proposed: a. The motion vectors of video units encoded and decoded using a specific prediction method are constrained by specific rules. a. A motion vector can refer to one or more of the following: i. Motion vector difference ii. Motion vector iii. Motion Vector Predictor b. The prediction method can refer to one or more of the following: i.IBC AMVP model ii. IBC Merger Mode iii. IBC merge mode with template matching iv. Intra-frame template matching v. IBC AMVP mode based on sample reordering vi. IBC merging mode based on sample reordering vii. Sample reordering based IBC merging mode with template matching viii. Intra-frame template matching based on sample reordering c. Rules may refer to one or more of the following: i. The horizontal component of the motion vector may be required to be equal to zero. ii. The vertical component of the motion vector may be required to be equal to zero. b. For example, assuming that the video unit is encoded using IBC AMVP mode, then the horizontal component of the motion vector may be required to be equal to zero. a. Alternatively, assuming the video unit is encoded using IBC AMVP mode, it may be required that the vertical component of the motion vector is equal to zero. b. In addition, the IBC AMVP mode in the disclosed black bullet can be replaced by the IBC Merge mode. c. In addition, the IBC AMVP mode in the disclosed black dots can be replaced by IBC with template matching mode. i. In one example, it may be necessary to search for template matches along one direction (horizontally or vertically). d. In addition, the IBC AMVP mode in the disclosed black dots can be replaced by the intra template matching mode. i. In one example, it may be necessary to search for template matches along one direction (horizontally or vertically). c. For example, assuming that the video unit is encoded in IBC AMVP mode based on sample reordering (eg, samples are flipped horizontally), the vertical component of the motion vector may be processed / constrained / required to be equal to zero. a. For example, assuming that the video unit is encoded in IBC AMVP mode based on sample reordering (eg, samples are flipped vertically), the horizontal component of the motion vector may be processed / constrained / required to be equal to zero. b. In addition, the IBC AMVP mode in the disclosed black dots can be replaced by the IBC Merge mode. c. In addition, the IBC AMVP mode in the disclosed black dots can be replaced by IBC with template matching mode. i. In one example, it may be necessary to search for template matches along the horizontal direction (vertical component of the motion vector equals 0) for horizontal flipping. ii. In one example, it may be necessary to search for template matches along the vertical direction (horizontal component of the motion vector equals 0) for vertical flipping. d. In addition, the IBC AMVP mode in the disclosed black dots can be replaced by the intra template matching mode. d. For example, if a component of the motion vector (eg, MVx or MVy) of a video unit is processed / constrained / required to be equal to zero, then a. The corresponding component of the motion vector difference (eg, MVDx or MVDy) of the video unit may be processed / constrained / required to be equal to zero. b. The corresponding component of the motion vector predictor (eg, MVPx or MVPy) of the video unit may be processed / constrained / required to be equal to zero. e. For example, if a certain component of the motion vector difference (eg, MVDx or MVDy) of a video unit is processed / constrained / required to be equal to zero, then a. The corresponding component of the motion vector difference may be inferred to be equal to zero without signaling. f. For example, the signaling of the motion vector difference (MVD) for a particular video unit may depend on the motion constraints applied to the video unit. a. For example, assuming that the MVDx of a video unit is processed / constrained / required to be equal to zero, the sign of MVDx may not be signaled. b. For example, assuming that the MVDy of a video unit is processed / constrained / required to be equal to zero, the sign of MVDy may not be signaled. g. For example, if the first component of a motion vector is processed / constrained / required to be equal to zero, then the first component of the corresponding MVD / MVP is processed / constrained / required to be equal to zero. h. The "zeros" in the above circle black dots may be replaced by any other fixed or derived or signaled value. 5.2.2 Regarding motion constraint-based AMVR signaling (e.g., the second question and related questions), the following approach is proposed: a. For example, the signaling of the resolution of the motion vector difference (eg, amvr_precision_idx of an AMVR) for a particular video unit may depend on the motion constraints applied to the video unit. a. For example, the video unit can utilize an AMVP mode codec. b. For example, the video unit may utilize the IBC AMVP codec. c. For example, the video unit may utilize IBC AMVP codec based on sample reordering. d. For example, the video unit can utilize the AMVP mode encoding and decoding based on sample reordering. e. For example, the signaling / presence of the resolution of the motion vector difference (e.g., amvr_precision_idx) can be decoupled from MVDx. For example, assuming that the MVDx of a video unit is processed / constrained / required to be equal to zero, then the signaling can only depend on whether the value of MVDy is equal to zero (rather than checking both MVDx and MVDy). f. For example, the signaling / presence of the resolution of the motion vector difference (e.g., amvr_precision_idx) can be decoupled from MVDy. For example, assuming that the MVDy of a video unit is processed / constrained / required to be equal to zero, then the signaling can only depend on whether the value of MVDx is equal to zero (rather than checking both MVDx and MVDy). g. For example, if the resolution of the motion vector difference (eg, amvr_precision_idx) is not signaled for such a video unit, it may be inferred to be equal to a certain value (such as 0) indicating that a default resolution is used. i. For example, when a video unit is encoded and decoded based on the IBC AMVP mode, the default resolution may be 1 pixel precision. ii. For example, in the case where the video unit is encoded and decoded according to the IBC AMVP mode based on sample reordering, the default resolution may be 1 pixel precision. b. For example, the signaling of amvr_precision_idx for an IBC AMVP codec block may be changed as follows (taking the syntax structure in the VVC specification as an example), where cu_ibc_reorder_type indicates whether and how to reorder samples in an IBC AMVP codec block. 5.2.3 Regarding template matching (e.g., intra TM, IBC with TM) modification with sample reordering enabled (e.g., the third problem and related problems), the following method is proposed: Assuming that the first template is for a first video unit utilizing TM codec with sample reordering, and the second template is for a second video unit utilizing TM codec without sample reordering: a. For example, the location of samples comprising a template may depend on the sample reordering method used for the video unit. a. For example, the sample positions of the first template and the second template may be different. b. For example, the second template can be constructed using samples above and to the left of the video unit. c. For example, the first template may be constructed using samples above or to the left of the video unit. i. For example, if the video unit is encoded with horizontal flipping, the first template can be constructed with samples above the video unit. ii. For example, if the video unit is encoded with vertical flipping, the first template may be constructed using samples on the left side of the video unit. d. Alternatively, the sample positions of the first template and the second template may be the same. b. For example, the number of samples comprising a template may depend on the sample reordering method used for the video unit. a. For example, the number of rows and / or columns of the first template and the second template may be different. b. For example, the second template may be constructed using M1 rows of samples above the video unit and N1 columns of samples on the left, while the first template may be constructed using M2 rows of samples above the video unit and / or N2 columns of samples on the left. The following rules may be met: i.M1!=m2 ii. N1! = n2 c. Alternatively, the number of rows and / or columns of the first template and the second template may be the same. 5.2.4 Regarding intra / IBC template matching based on sample reordering (e.g., the fourth problem and related problems), the following method is proposed: a. How to derive the reference template of the sample reordering codec block may depend on the codec information. a. For example, it may depend on the sample reordering type and / or template shape to be used for the current block. b. Sample Reordering Codec The derivation of the motion vector (block vector) of a block may depend on codec information. a. For example, it may depend on the sample reordering type and / or template shape to be used for the current block. b. For example, it may depend on the dimensions of the current block (such as width and / or height). c. For example, it may depend on the dimensions (such as width and / or height) of the template (or part of the template). d. For example, it may depend on the coordinates of the position of the current block or template (eg, the center sample position or the top left sample position). i. For example, the template can be a current template and / or a reference template. c. Figures 20A-20H , where a dotted line indicates that flipping is performed across the dotted line (i.e., a horizontal dotted line indicates a vertical flip, which means flipping upside down, and a vertical dotted line indicates a horizontal flip, which means flipping left to right), a blue rectangle indicates a current block and a current template, an orange rectangle indicates a reference block and a reference template, BV'x and BV'y indicate the horizontal and vertical displacements between the current template and the reference template, respectively, BVx and BVy indicate the horizontal and vertical displacements between the current block and the reference block, respectively, (W cur , H cur ) represents the width and height of the current block, (W tmpH , H tmpH ) represents the width and height of the horizontal template along the block width direction, (W tmpV , H tmpV ) represents the width and height of the vertical template along the block height direction, (x1, y1) and (x2, y2) represent the coordinates of the upper left samples of the current block and the reference block, respectively, (x1', y1') and (x2', y2') represent the coordinates of the upper left samples of the current horizontal template and the reference horizontal template, respectively, (x1", y1") and (x2", y2") represent the coordinates of the upper left samples of the current vertical template and the reference vertical template, respectively. a. For example, in the case of a horizontal template and horizontal flip (i.e., Fig. 20A ), i. In one example, both the current template and the reference template may include neighboring samples above the current block. ii. In one example, the relative position of (current block, current template) and the relative position of (reference block, reference template) may be the same. 1. In one example, x1-x1'=x2-x2', and y1-y1'=y2-y2'. 2. In one example, x1-x1'=0, and y1-y1'=H tmpH iii. In one example, the samples in the current template or the samples in the reference template may be flipped. iv. In one example, the samples in the current template may be flipped according to the flip type being checked (eg, horizontal flip). v. In one example, the samples in the reference template may be flipped according to the flip type being checked (eg, horizontal flip). vi. In one example, BVx = BV'x vii. In one example, x1'-x2'=x1-x2 b. For example, in the case of a vertical template and horizontal flip (i.e., Fig. 20B ), i. In one example, the current template may include neighboring samples on the left side of the current block, and the reference template may include neighboring samples on the right side of the current block. ii. In one example, the relative position of (current block, current template) and the relative position of (reference block, reference template) may be different. 1. In one example, x1-x1"!=x2-x2", and y1-y1"=y2-y2" 2. In one example, x1-x1″=W tmpV , and y1-y1”=0 3. In one example, x2-x2" = -W cur , and y2-y2”=0 iii. In one example, the samples in the current template or the samples in the reference template may be flipped. iv. In one example, the samples in the current template may be flipped according to the flip type being checked (eg, horizontal flip). v. In one example, the samples in the reference template may be flipped according to the flip type being checked (eg, horizontal flip). vi. In one example, BVx = BV'x - W cur -W tmpV vii. In one example, x2"-x1"-W cur -W tmpV =x2-x1 c. For example, in the horizontal-vertical template (where W tmpH =W cur ) and horizontal flip (i.e., Fig. 20C ), i. In one example, the current template may include neighboring samples above and to the left of the current block, and the reference template may include neighboring samples above and to the right of the current block. ii. In one example, the relative position of (current block, current horizontal template) and the relative position of (reference block, reference horizontal template) may be the same. 1. In one example, x1-x1'=x2-x2', and y1-y1'=y2-y2'. 2. In one example, x1-x1'=0, and y1-y1'=H tmpH iii. In one example, the relative position of (current block, current vertical template) and the relative position of (reference block, reference vertical template) may be different. 1. In one example, x1-x1'! = x2-x2", and y1-y1" = y2-y2" 2. In one example, x1-x1″=W tmpV , and y1-y1”=0 3. In one example, x2-x2" = -W cur , and y2-y2”=0 iv. In one example, samples in the current horizontal template or samples in the reference horizontal template may be flipped. 1. In addition, the samples in the current vertical template or the samples in the reference vertical template can be flipped. v. In one example, the samples in the current horizontal and vertical templates may be flipped according to the flip type being checked (eg, horizontal flip). vi. In one example, samples in the reference horizontal and vertical templates may be flipped according to the flip type being checked (eg, horizontal flip). vii. In one example, BVx = BV'x viii. In one example, x1'-x2'=x1-x2 d. For example, in the horizontal-vertical template (where W tmpH =W cur +W tmpV ) and horizontal flip (i.e., Fig.20D ), i. In one example, the current template may include neighboring samples above and to the left of the current block, and the reference template may include neighboring samples above and to the right of the current block. ii. In one example, the relative position of (current block, current horizontal template) and the relative position of (reference block, reference horizontal template) may be different. 1. In one example, x1-x1'! = x2-x2', and y1-y1' = y2-y2' 2. In one example, x1-x1'=W tmpV , and y1-y1'=H tmpH 3. In one example, x2-x2'=0, and y2-y2'=H tmpH iii. In one example, the relative position of (current block, current vertical template) and the relative position of (reference block, reference vertical template) may be different. 1. In one example, x1-x1"!=x2-x2", and y1-y1"=y2-y2" 2. In one example, x1-x1″=W tmpV , and y1-y1”=0 3. In one example, x2-x2" = -W cur , and y2-y2”=0 iv. In one example, the samples in the current horizontal template or the samples in the reference horizontal template may be flipped. 1. In addition, the samples in the current vertical template or the samples in the reference vertical template can be flipped. v. In one example, the samples in the current horizontal and vertical templates may be flipped according to the flip type being checked (eg, horizontal flip). vi. In one example, samples in the reference horizontal and vertical templates may be flipped according to the flip type being checked (eg, horizontal flip). vii. In one example, BVx = BV'x - W tmpV viii. In one example, x2'-x1'-W tmpV =x2-x1 e. For example, in the case of a horizontal template and vertical flip (i.e. Fig.20E ), i. In one example, the current template may include neighboring samples above the current block, and the reference template may include neighboring samples below the current block. ii. In one example, the relative position of (current block, current template) and the relative position of (reference block, reference template) may be different. 1. In one example, x1-x1'=x2-x2', and y1-y1'!=y2-y2' 2. In one example, x1-x1'=0, and y1-y1'=H tmpH 3. In one example, x2-x2'=0, and y2-y2'=-H cur iii. In one example, the samples in the current template or the samples in the reference template may be flipped. iv. In one example, the samples in the current template may be flipped according to the flip type being checked (eg, vertical flip). v. In one example, the samples in the reference template may be flipped according to the flip type being checked (eg, vertical flip). vi. In one example, BVy = BV'y - H tmpH -H cur vii. In one example, y2'-y1'-H tmpH -H cur =y2-y1 f. For example, in the case of vertical template and vertical flip (i.e., Fig.20F ), i. In one example, both the current template and the reference template may include neighboring samples to the left of the current block. ii. In one example, the relative position of (current block, current template) and the relative position of (reference block, reference template) may be the same. 1. In one example, x1-x1″=x2-x2″, and y1-y1″=y2-y2″ 2. In one example, x1-x1″=W tmpV , and y1-y1”=0 iii. In one example, the samples in the current template or the samples in the reference template may be flipped. iv. In one example, the samples in the current template may be flipped according to the flip type being checked (eg, vertical flip). v. In one example, the samples in the reference template may be flipped according to the flip type being checked (eg, vertical flip). vi. In one example, BVy = BV'y vii. In one example, y1"-y2"=y1-y2 g. For example, in the horizontal-vertical template (where W tmpH =W cur ) and vertical flip (i.e., Figure 20G ), i. In one example, the current template may include neighboring samples above and to the left of the current block, and the reference template may include neighboring samples to the left and below the current block. ii. In one example, the relative position of (current block, current horizontal template) and the relative position of (reference block, reference horizontal template) may be different. 1. In one example, x1-x1'=x2-x2', and y1-y1'!=y2-y2' 2. In one example, x1-x1'=0, and y1-y1'=H tmpH 3. In one example, x2-x2'=0, and y2-y2'=-H cur iii. In one example, the relative position of (current block, current vertical template) and the relative position of (reference block, reference vertical template) may be the same. 1. In one example, x1-x1″=x2-x2″, and y1-y1″=y2-y2″ 2. In one example, x1-x1″=W tmpV , and y1-y1”=0 iv. In one example, samples in the current horizontal template or samples in the reference horizontal template may be flipped. 1. In addition, the samples in the current vertical template or the samples in the reference vertical template can be flipped. v. In one example, the samples in the current horizontal template and the vertical template may be flipped according to the flip type being checked (eg, vertical flip). vi. In one example, samples in the reference horizontal and vertical templates may be flipped according to the flip type being checked (eg, vertical flip). vii. In one example, BVy = BV'y - H tmpH -H cur viii. In one example, y2'-y1'-H tmpH -H cur =y2-y1 h. For example, in the horizontal-vertical template (where W tmpH =W cur +W tmpV ) and vertical flip (i.e., Fig. 20H ), i. In one example, the current template may include neighboring samples above and to the left of the current block, and the reference template may include neighboring samples to the left and below the current block. ii. In one example, the relative position of (current block, current horizontal template) and the relative position of (reference block, reference horizontal template) may be different. 1. In one example, x1-x1'=x2-x2', and y1-y1''!=y2-y2' 2. In one example, x1-x1'=W tmpV , and y1-y1'=H tmpH 3. In one example, x2-x2'=W tmpV , y2-y2'=-H cur iii. In one example, the relative position of (current block, current vertical template) and the relative position of (reference block, reference vertical template) may be the same. 1. In one example, x1-x1″=x2-x2″, and y1-y1″=y2-y2″ 2. In one example, x1-x1″=W tmpV , and y1-y1”=0. iv. In one example, samples in the current horizontal template or samples in the reference horizontal template may be flipped. 1. In addition, the samples in the current vertical template or the samples in the reference vertical template can be flipped. v. In one example, the samples in the current horizontal template and the vertical template may be flipped according to the flip type being checked (eg, vertical flip). vi. In one example, samples in the reference horizontal and vertical templates may be flipped according to the flip type being checked (eg, vertical flip). vii. In one example, BVy = BV'y - H tmpH -H cur viii. In one example, y2'-y1'-H tmpH -H cur =y2-y1 5.2.5 Regarding motion search with template matching when the sample reordering method is applied (e.g., the fifth problem and related problems), the following method is proposed: a. In one example, for a sample reordering method (such as vertical flipping or horizontal flipping), samples in a template surrounding a current block may be reordered to obtain a cost before being compared with samples in a template surrounding a reference block (which are not reordered). b. In one example, for a sample reordering method (such as vertical flipping or horizontal flipping), samples in a template surrounding a reference block may be reordered to obtain a cost before being compared with samples in a template surrounding a current block (which are not reordered). c. In one example, for a sample reordering method (such as vertical flipping or horizontal flipping), the samples in both the template around the reference block and the template around the current block may be reordered to obtain the cost before comparing them. 5.2.6 Regarding how to determine a sample reordering method (such as no flipping, vertical flipping, or horizontal flipping) for a coding block for template matching (such as intra-frame template matching and / or IBC mode with template matching) (e.g., the sixth question and related questions), the following method is proposed: a. In one example, the sample reordering method may depend on at least one syntax element signaled from the encoder to the decoder. i. In one example, a syntax element may indicate whether and / or how to reorder samples for a template matching codec block (such as intra template matching and / or IBC mode with template matching, etc.). ii. The syntax element may be encoded in the same way as used to indicate whether and / or how to reorder samples of a block encoded for a specific prediction method, such as IBC. b. In one example, a sample reordering method may be derived based on at least one template cost. i. In one example, a motion search with templates matching different sample reordering methods may be applied for a block to derive a minimum cost for the different sample reordering methods. ii. In one example, a sample reordering method with a minimum template cost may be derived as the determined sample reordering method. General Requirements 5.2.7 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. 5.2.8 Whether and / or how to apply the above disclosed methods may be signaled at a PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / tile / sub-picture / other kind of region containing more than one sample or pixel. 5.2.9 Whether and / or how to apply the above disclosed method may depend on the codec information, such as block size, color format, single tree / dual tree partitioning, color component, slice / picture type.

[0088] As used herein, the term "video unit" or "video block" may be a sequence, picture, slice, tile, block, sub-picture, codec tree unit (CTU) / codec tree block (CTB), CTU / CTB row, one or more codec units (CU) / codec blocks (CB), one or more CTU / CTB, one or more virtual pipeline data units (VPDU), sub-region within a picture / slice / tile / block. The term "image compression" may refer to any variance of a signal processing method that compresses or processes the current input. Input images / videos include, but are not limited to, screen content and natural content.

[0089] Fig.21 A flow chart of a method 2100 for video processing according to an embodiment of the present disclosure is shown. The method 2100 is implemented during conversion between a video unit of a video and a bit stream of the video.

[0090] At block 2110, for conversion between a video unit of a video and a bitstream of the video, an intra mode for the video unit is generated based on codec information associated with the video unit. The video unit may be an intra template matching (TM) codec block. Alternatively, the video unit may be an intra copy block (IBC) codec block.

[0091] At block 2120, conversion is performed based on the generated intra-mode. In this way, the codec efficiency of the block vector codec can be improved. In some embodiments, the conversion may include encoding and decoding the video unit into a bitstream. Alternatively or additionally, the conversion may include decoding the video unit from the bitstream.

[0092] In some embodiments, generating the intra mode comprises: generating the intra mode based on the codec information of the intra TM codec block. In some embodiments, the generated intra mode is derived based on the gradient of the intra TM codec block. In some embodiments, based on the gradient, the converted or mapped intra mode is generated and stored as the intra mode of the intra TM codec block.

[0093] In some embodiments, the generated intra-mode is derived based on a block vector of an intra-TM codec block. In some embodiments, the direction of the block vector is utilized. In some embodiments, based on the direction or angle of the block vector, a converted or mapped intra-mode is generated and stored as an intra-mode of an intra-TM codec block.

[0094] In some embodiments, the generated intra mode is derived based on a mapping table.In some embodiments, the mapping table comprises at least one entry based on a block vector of an intra TM coded block.

[0095] In some embodiments, the generated intra mode of the intra TM codec block is stored in a buffer. In some embodiments, the prediction block of the intra TM codec block is not generated based on the generated intra mode. In some embodiments, the stored intra mode of the intra TM codec block is used for coding of a subsequent block.

[0096] In some embodiments, the intra TM based prediction block is combined with a second prediction block. For example, the intra TM based prediction block is combined with a decoder side intra mode derivation (DIMD) prediction block. In some embodiments, the intra TM based prediction block is combined with a template based intra mode derivation (TIMD) prediction block. In some embodiments, the intra TM based prediction block is combined with a multiple hypothesis prediction (MHP) prediction block. In some embodiments, the intra TM based prediction block is combined with an intra block copy (IBC) prediction block.

[0097] In some embodiments, the block vector of the intra TM codec block is used for the encoding and decoding of the subsequent block. In this case, the encoding and decoding of the subsequent block includes at least one of the following processes: IBC prediction list generation, TIMD-based mode derivation, TIMD-based prediction derivation or DIMD-based mode derivation, DIMD-based prediction derivation. In some embodiments, the IBC prediction list generation includes at least one of the following: an advanced motion vector prediction (AMVP) list for a conventional IBC mode, a merge list for a conventional IBC mode, an AMVP list for an IBC-TM mode, a merge list for an IBC-TM mode, an AMVP list for an IBC merge mode with a motion vector difference (MMVD) mode, a merge list for an IBC-MMVD mode, an AMVP list for reconstructing a reordered IBC (RRIBC), or a merge list for RRIBC.

[0098] In some embodiments, intra TM is used for chroma blocks in at least one of the following: single tree or dual tree. In some embodiments, in dual tree, the block vectors for chroma intra TM are derived based on the block vectors for the corresponding luma intra TM (without searching). In some embodiments, in dual tree, the intra TM flags for chroma blocks are inherited from the corresponding luma blocks (without signaling). In some embodiments, in dual tree, if the chroma blocks are coded as intra distribution matching (INTRA_DM) mode and the luma blocks are coded as intra TM mode, then chroma is coded as intra TM mode.

[0099] In some embodiments, in a single tree, the block vectors for the chroma intra TM are derived based on the block vectors for the corresponding luma intra TM. In some embodiments, in a single tree, if the chroma block is coded as INTRA_DM mode and the luma block is coded as intra TM mode, the chroma block is coded as intra TM mode based on the block vectors of the luma block. In some embodiments, in a single tree, the chroma intra TM shares the same intra TM syntax (e.g., flags used by intra TM) as the luma intra TM. In some embodiments, in a single tree, searching for the block vectors for the intra TM coded blocks considers costs from both luma and chroma blocks.

[0100] In some embodiments, generating the intra mode comprises: generating the intra mode based on codec information of a reference block of the intra TM codec block. In some embodiments, the reference block is derived based on a block vector of the intra TM codec block.

[0101] In some embodiments, the generated intra-mode of the intra TM codec block is derived based on at least one of: the intra-mode of a reference block (e.g., an intra-mode index, an intra-mode angle, etc.), the gradient of the reference block, the prediction mode of the reference block, or the codec information of a codec unit covering the reference block (e.g., a prediction mode, an intra-mode index, an intra-mode angle, etc.).

[0102] In some embodiments, if the coding unit (CU) covering the reference block includes multiple candidate blocks, one of the multiple intra modes is selected for the generated intra mode. For example, the selected rule is based on the prediction mode of the multiple candidate blocks (e.g., it is an intra mode and / or an intra TM and / or an IBC prediction). In some embodiments, the selected rule is based on a predefined candidate block checking order. In some embodiments, the selected rule is based on the position of the multiple candidate blocks relative to the intra TM block. In some embodiments, the selected rule is based on a template cost.

[0103] In some embodiments, if at least one of the reference block or the CU covering the reference block is not coded in one of: intra mode, IBC mode or intra TM mode, planar mode is used as the generated intra mode.

[0104] In some embodiments, the generated intra mode of the intra TM codec block is used for the coding of the following block. In this case, the coding of the following block includes at least one of the following processes: most likely mode (MPM) list generation, TIMD mode derivation, TIMD prediction derivation, DIMD-based mode derivation, DIMD-based prediction derivation, fusion-based mode derivation, fusion-based prediction derivation, or deblocking filter.

[0105] In some embodiments, MPM list generation includes at least one of: an MPM list for conventional intra mode, an MPM list for geometric partitioning mode (GPM)-intra-inter mode, an MPM list for spatial GPM intra mode, an MPM list for multi-linear regression intra prediction (MIP) mode, an MPM list for TIMD mode, a first MPM list for video codec, or a second MPM list for video codec.

[0106] In some embodiments, the deblocking filter includes a deblocking strength (eg, long filter, short filter, strong filter, weak filter, etc.) Alternatively or additionally, the deblocking filter includes a filter strength of the deblocking process (eg, derivation of a bS value).

[0107] In some embodiments, the IBC-based prediction block is combined with a second prediction block. In some embodiments, the IBC-based prediction block is combined with a DIMD prediction block. In some embodiments, the IBC-based prediction block is combined with a TIMD prediction block. In some embodiments, the IBC-based prediction block is combined with an MHP prediction block. In some embodiments, the IBC-based prediction block is combined with an intra TM prediction block.

[0108] In some embodiments, the generated intra-mode is generated for a BIC codec block and is used for at least one of: intra-mode coding or intra-mode prediction of a subsequent / future block.

[0109] In some embodiments, generating the intra mode comprises: generating the intra mode based on codec information of a reference block of the IBC codec block. In some embodiments, the reference block is derived based on a block vector of the IBC codec block. In some embodiments, the generated intra mode (e.g., an intra mode index, an intra mode angle, etc.) of the IBC codec block is derived based on at least one of the following: an intra mode of the reference block, a gradient of the reference block, a prediction mode of the reference block, or codec information (e.g., a prediction mode, an intra mode index, an intra mode angle, etc.) of a codec unit covering the reference block.

[0110] In some embodiments, if the CU covering the reference block includes multiple candidate blocks, then for the generated intra mode, one of the multiple intra modes is selected. In some embodiments, the selected rule is based on the prediction mode of the multiple candidate blocks (for example, it is an intra mode and / or an intra TM and / or an IBC prediction). In some embodiments, the selected rule is based on a predefined candidate block check order. In some embodiments, the selected rule is based on the position of the multiple candidate blocks relative to the intra TM block. In some embodiments, the selected rule is based on a template cost. In some embodiments, if at least one of the reference block or the CU covering the reference block is not encoded or decoded by at least one of the following: intra mode, IBC mode, or intra TM mode, then the planar mode is used as the generated intra mode.

[0111] In some embodiments, generating the intra-mode includes: generating the intra-mode based on the codec information of the IBC codec block. In some embodiments, the generated intra-mode is derived based on the block vector of the IBC codec block. In some embodiments, the direction of the block vector is utilized. In some embodiments, based on the direction or angle of the block vector, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

[0112] In some embodiments, the generated intra-mode is derived based on a mapping table.In some embodiments, the mapping table comprises at least one entry based on a block vector of an IBC codec block.

[0113] In some embodiments, the generated intra-mode is derived based on the gradient of the IBC codec block.In some embodiments, based on the gradient, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

[0114] In some embodiments, the generated intra-mode of the IBC codec block is stored in a buffer. In some embodiments, the prediction block of the IBC codec block is not generated based on the generated intra-mode. In some embodiments, the stored intra-mode of the IBC codec block is used for encoding and decoding of a subsequent block.

[0115] In some embodiments, the generated intra mode of the IBC codec block is used for the coding of the latter block. In this case, the coding of the latter block includes at least one of the following processes: most probable mode (MPM) list generation, TIMD mode derivation, TIMD prediction derivation, DIMD-based mode derivation, DIMD-based prediction derivation, fusion-based mode derivation, fusion-based prediction derivation, or deblocking filter. In some embodiments, the MPM list generation includes at least one of the following: an MPM list for conventional intra mode, an MPM list for geometric partitioning mode (GPM)-intra-inter mode, an MPM list for spatial GPM intra mode, an MPM list for multi-linear regression intra prediction (MIP) mode, an MPM list for TIMD mode, a first MPM list for video coding, or a second MPM list for video coding. In some embodiments, the deblocking filter includes a deblocking strength (e.g., a long filter, a short filter, a strong filter, a weak filter, etc.). Alternatively, the deblocking filter includes a filter strength of the deblocking process (e.g., the derivation of bS values).

[0116] In some embodiments, the indication of whether and / or how the intra mode is generated based on the codec information is indicated in one of the following: sequence level, picture group level, picture level, slice level, or tile group level. In some embodiments, the indication of whether and / or how the intra mode is generated based on the codec information is indicated in one of the following: sequence header, picture header, sequence parameter set (SPS), video parameter set (VPS), dependency parameter set (DPS), decoding capability information (DCI), picture parameter set (PPS), adaptation parameter set (APS), slice header, or tile group header. In some embodiments, the indication of whether and / or how the intra mode is generated based on the codec information is included in one of the following: prediction block (PB), transform block (TB), codec block (CB), prediction unit (PU), transform unit (TU), codec unit (CU), virtual pipeline data unit (VPDU), codec tree unit (CTU), CTU row, slice, tile, sub-picture; or a region containing more than one sample or pixel.

[0117] In some embodiments, method 2100 also includes: based on the codec information of the video unit, determining whether and / or how to generate an intra-frame mode based on the codec information, the codec information including at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[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, and the bitstream of the video is generated by a method performed by a device for video processing. The method includes: generating an intra-frame mode for a video unit based on codec information associated with a video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; and generating a bitstream based on the generated intra-frame mode.

[0119] According to some other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. The method includes: generating an intra-frame mode for a video unit based on codec information associated with the video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; generating a bitstream based on the generated intra-frame mode; and storing the bitstream in a non-transitory computer-readable recording medium.

[0120] Fig. 22 A flowchart of a method 2200 for video processing according to an embodiment of the present disclosure is shown.

[0121] At block 2210, for conversion between a video unit of a video and a bitstream of the video, at least one codec tool is determined for which screen content codec for the video unit is to be disabled.

[0122] At block 2220, conversion is performed based on the determination. In this way, the codec efficiency of the block vector codec can be improved. In some embodiments, the conversion can include encoding and decoding the video unit into a bitstream. Alternatively or additionally, the conversion can include decoding the video unit from the bitstream.

[0123] In some embodiments, at least one codec tool is selected from the following: decoder-side intra mode derivation (DIMD), a variant of DIMD, template-based intra mode derivation (TIMD), a variant of TIMD, overlapped block motion compensation (OBMC), a variant of OBMC, local illumination compensation (LIC), a variant of LIC, multiple hypothesis prediction (MHP), a variant of MHP, combined intra / inter prediction mode (CIIP), a variant of CIIP, a fusion process of two predictions, deblocking, a variant of deblocking, adaptive loop filtering (ALF), a variant of ALF, screen content coding (SCC), a variant of SCC, bilateral filtering, or a variant of bilateral filtering.

[0124] In some embodiments, high-level syntax is indicated at one of the following levels to indicate whether at least one codec tool is disabled for screen content encoding: sequence parameter set (SPS), picture parameter set (PPS), picture header (PH), or sequence header (SH).

[0125] In some embodiments, whether and / or how to determine the indication of at least one codec tool to be disabled is indicated in one of the following: sequence level, picture group level, picture level, slice level, or tile group level. In some embodiments, whether and / or how to determine the indication of at least one codec tool to be disabled is indicated in one of the following: sequence header, picture header, sequence parameter set (SPS), video parameter set (VPS), dependency parameter set (DPS), decoding capability information (DCI), picture parameter set (PPS), adaptation parameter set (APS), slice header, or tile group header. In some embodiments, whether and / or how to determine the indication of at least one codec tool to be disabled is included in one of the following: prediction block (PB), transform block (TB), codec block (CB), prediction unit (PU), transform unit (TU), codec unit (CU), virtual pipeline data unit (VPDU), codec tree unit (CTU), CTU row, slice, tile, sub-picture, or a region containing more than one sample or pixel. In some embodiments, method 2200 further includes determining whether and / or how to determine at least one codec tool to be disabled based on codec information of the video unit, the codec information including at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[0126] 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, and the bitstream of the video is generated by a method performed by a device for video processing. The method includes: determining at least one codec tool for which screen content codec of a video unit of the video will be disabled; and generating a bitstream based on the determination.

[0127] According to some other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. The method includes: determining at least one codec tool for which screen content coding of a video unit of the video is to be disabled; generating a bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium.

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

[0129] Item 1. A method of video processing, comprising: converting between a video unit of a video and a bitstream of the video, generating an intra-frame mode for the video unit based on codec information associated with the video unit, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; and performing the conversion based on the generated intra-frame mode.

[0130] Clause 2. The method of clause 1, wherein generating the intra mode comprises generating the intra mode based on codec information of the intra TM codec block.

[0131] Clause 3. The method of clause 2, wherein the generated intra mode is derived based on a gradient of the intra TM codec block.

[0132] Clause 4. The method of clause 3, wherein based on the gradient, a converted or mapped intra mode is generated and stored as the intra mode of the intra TM codec block.

[0133] Clause 5. The method of clause 2, wherein the generated intra mode is derived based on a block vector of the intra TM codec block.

[0134] Clause 6. The method of clause 5, wherein the direction of the block vector is utilized.

[0135] Clause 7. The method of clause 5, wherein based on the direction or angle of the block vector, a converted or mapped intra mode is generated and stored as the intra mode of the intra TM codec block.

[0136] Clause 8. The method of clause 2, wherein the generated intra-mode is derived based on a mapping table.

[0137] Clause 9. The method of clause 8, wherein the mapping table comprises at least one entry based on a block vector of the intra TM coded block.

[0138] Clause 10. The method of clause 1, wherein the generated intra-mode of the intra TM codec block is stored in a buffer.

[0139] Clause 11. The method of clause 10, wherein a prediction block for the intra TM codec block is not generated based on the generated intra mode.

[0140] Clause 12. The method of clause 10, wherein the stored intra mode of the intra TM codec block is used for coding of a subsequent block.

[0141] Clause 13. The method of clause 1, wherein the intra TM based prediction block is combined with the second prediction block.

[0142] Clause 14. The method of clause 13, wherein the intra TM based prediction block is combined with a decoder side intra mode derived (DIMD) prediction block.

[0143] Clause 15. The method of clause 13, wherein the intra TM based prediction block is combined with a template based intra mode derivation (TIMD) prediction block.

[0144] Clause 16. The method of clause 13, wherein the intra TM based prediction block is combined with a multiple hypothesis prediction (MHP) prediction block.

[0145] Clause 17. The method of clause 13, wherein the intra TM based prediction block is combined with an intra block copy (IBC) prediction block.

[0146] Clause 18. A method according to clause 1, wherein the block vector of the intra-frame TM codec block is used for encoding and decoding of a subsequent block, wherein the encoding and decoding of the subsequent block includes at least one of the following processes: IBC prediction list generation, TIMD-based mode derivation, TIMD-based prediction derivation, or DIMD-based mode derivation, DIMD-based prediction derivation.

[0147] Clause 19. A method according to clause 18, wherein the IBC prediction list generation includes at least one of the following: an advanced motion vector prediction (AMVP) list for a regular IBC mode, a merge list for a regular IBC mode, an AMVP list for an IBC-TM mode, a merge list for an IBC-TM mode, an AMVP list for an IBC merge mode with a motion vector difference (MMVD) mode, a merge list for an IBC-MMVD mode, an AMVP list for reconstructed reordered IBC (RRIBC), or a merge list for RRIBC.

[0148] Clause 20. The method of clause 1, wherein intra TM is used for chroma blocks in at least one of: single tree or dual tree.

[0149] Clause 21. The method of clause 20, wherein in the dual tree, block vectors for chroma intra TMs are derived based on block vectors for corresponding luma intra TMs.

[0150] Clause 22. The method of clause 20, wherein in the dual tree, the intra TM flag of the chroma block is inherited from the corresponding luma block.

[0151] Clause 23. The method of clause 20, wherein in the dual tree, if the chroma block is coded as intra distribution matching (INTRA_DM) mode and the luma block is coded as intra TM mode, then the chroma is coded as intra TM mode.

[0152] Clause 24. The method of clause 20, wherein in the single tree, block vectors for chroma intra TMs are derived based on block vectors for corresponding luma intra TMs.

[0153] Clause 25. A method according to clause 20, wherein in the single tree, if the chroma block is encoded as INTRA_DM mode and the luma block is encoded as intra TM mode, then the chroma block is encoded as intra TM mode based on the block vector of the luma block.

[0154] Clause 26. The method of clause 20, wherein in the single tree, chroma intra TM and luma intra TM share the same intra TM syntax.

[0155] Clause 27. The method of clause 20, wherein in the single tree, searching for block vectors for intra TM-coded blocks considers costs from both luma blocks and chroma blocks.

[0156] Clause 28. The method of clause 1, wherein generating the intra mode comprises generating the intra mode based on codec information of a reference block of the intra TM codec block.

[0157] Clause 29. The method of clause 28, wherein the reference block is derived based on a block vector of the intra TM coded block.

[0158] Clause 30. A method according to clause 28, wherein the generated intra-mode of the intra-TM codec block is derived based on at least one of: the intra-mode of the reference block, the gradient of the reference block, the prediction mode of the reference block, or the codec information of the codec unit covering the reference block.

[0159] Clause 31. The method of clause 28, wherein if a codec unit (CU) covering the reference block includes a plurality of candidate blocks, one intra-mode of a plurality of intra-modes is selected for the generated intra-mode.

[0160] Clause 32. The method of clause 31, wherein the selection rule is based on prediction modes of the plurality of candidate blocks.

[0161] Clause 33. The method of clause 31, wherein the selected rule is based on a predefined candidate block checking order.

[0162] Clause 34. The method of clause 31, wherein a rule for the selection is based on a position of the plurality of candidate blocks relative to the intra TM block.

[0163] Clause 35. The method of clause 31, wherein the selection rule is based on template cost.

[0164] Clause 36. A method according to clause 28, wherein if at least one of the reference block or the CU covering the reference block is not encoded or decoded by one of the following: intra mode, IBC mode or intra TM mode, then planar mode is used as the generated intra mode.

[0165] Clause 37. A method according to clause 1, wherein the intra mode generated by the intra TM codec block is used for coding of a subsequent block, wherein the coding of the subsequent block includes at least one of the following processes: most probable mode (MPM) list generation, TIMD mode derivation, TIMD prediction derivation, DIMD-based mode derivation, DIMD-based prediction derivation, fusion-based mode derivation, fusion-based prediction derivation, or a deblocking filter.

[0166] Clause 38. A method according to Clause 37, wherein the MPM list generation includes at least one of the following: an MPM list for a conventional intra mode, an MPM list for a geometric partitioning mode (GPM)-intra-inter mode, an MPM list for a spatial GPM intra mode, an MPM list for a multi-linear regression intra prediction (MIP) mode, an MPM list for a TIMD mode, a first MPM list for video codec, or a second MPM list for video codec.

[0167] Clause 39. The method of clause 37, wherein the deblocking filter comprises a deblocking strength, or wherein the deblocking filter comprises a filter strength of a deblocking process.

[0168] Clause 40. The method of clause 1, wherein the IBC-based prediction block is combined with a second prediction block.

[0169] Clause 41. The method of clause 40, wherein the IBC-based prediction block is combined with a DIMD prediction block.

[0170] Clause 42. The method of clause 40, wherein the IBC-based prediction block is combined with a TIMD prediction block.

[0171] Clause 43. The method of clause 40, wherein the IBC-based prediction block is combined with an MHP prediction block.

[0172] Clause 44. The method of clause 40, wherein the IBC-based prediction block is combined with an intra TM prediction block.

[0173] Clause 45. The method of clause 1, wherein the generated intra-mode is generated for the BIC codec block and is used for at least one of: intra-mode coding or intra-mode prediction of a subsequent block.

[0174] Clause 46. The method of clause 1, wherein generating the intra mode comprises generating the intra mode based on codec information of a reference block of the IBC codec block.

[0175] Clause 47. The method of clause 46, wherein the reference block is derived based on a block vector of the IBC codec block.

[0176] Clause 48. A method according to clause 46, wherein the generated intra-frame mode of the IBC codec block is derived based on at least one of the following: the intra-frame mode of the reference block, the gradient of the reference block, the prediction mode of the reference block, or the codec information of the codec unit covering the reference block.

[0177] Clause 49. The method of clause 46, wherein if the CU covering the reference block includes a plurality of candidate blocks, then for the generated intra-mode, one of the plurality of intra-modes is selected.

[0178] Clause 50. The method of clause 49, wherein the selected rule is based on prediction modes of the plurality of candidate blocks.

[0179] Clause 51. The method of clause 49, wherein the selected rule is based on a predefined candidate block checking order.

[0180] Clause 52. The method of clause 49, wherein a rule for the selection is based on a position of the plurality of candidate blocks relative to the intra TM block.

[0181] Clause 53. The method of clause 49, wherein the selection rule is based on template cost.

[0182] Clause 54. A method according to clause 46, wherein if at least one of the reference block or the CU covering the reference block is not encoded or decoded by at least one of the following: intra mode, IBC mode or intra TM mode, then planar mode is used as the generated intra mode.

[0183] Clause 55. The method of clause 1, wherein generating the intra-mode comprises generating the intra-mode based on codec information of the IBC codec block.

[0184] Clause 56. The method of clause 55, wherein the generated intra-mode is derived based on a block vector of the IBC codec block.

[0185] Clause 57. The method of clause 56, wherein the direction of the block vector is utilized.

[0186] Clause 58. The method of clause 56, wherein based on the direction or angle of the block vector, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

[0187] Clause 59. The method of clause 55, wherein the generated intra-mode is derived based on a mapping table.

[0188] Clause 60. The method of clause 59, wherein the mapping table includes at least one entry based on a block vector of the IBC codec block.

[0189] Clause 61. The method of clause 55, wherein the generated intra-mode is derived based on a gradient of the IBC codec block.

[0190] Clause 62. The method of clause 61, wherein based on the gradient, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

[0191] Clause 63. The method of clause 1, wherein the generated intra-mode of the IBC codec block is stored in a buffer.

[0192] Clause 64. The method of clause 63, wherein a prediction block of the IBC codec block is not generated based on the generated intra mode.

[0193] Clause 65. The method of clause 63, wherein the stored intra-mode of the IBC codec block is used for coding of a subsequent block.

[0194] Clause 66. A method according to Clause 1, wherein the intra-frame mode generated by the IBC codec block is used for coding of a subsequent block, wherein the coding of the subsequent block includes at least one of the following processes: most probable mode (MPM) list generation, TIMD mode derivation, TIMD prediction derivation, DIMD-based mode derivation, DIMD-based prediction derivation, fusion-based mode derivation, fusion-based prediction derivation, or a deblocking filter.

[0195] Clause 67. A method according to Clause 66, wherein the MPM list generation includes at least one of the following: an MPM list for a conventional intra mode, an MPM list for a geometric partitioning mode (GPM)-intra-inter mode, an MPM list for a spatial GPM intra mode, an MPM list for a multi-linear regression intra prediction (MIP) mode, an MPM list for a TIMD mode, a first MPM list for a video codec, or a second MPM list for a video codec.

[0196] Clause 68. The method of clause 66, wherein the deblocking filter comprises a deblocking strength, or wherein the deblocking filter comprises a filter strength of a deblocking process.

[0197] Clause 69. A method according to any one of clauses 1-68, wherein the indication of whether and / or how the intra-mode is generated based on the codec information is indicated at one of: sequence level, picture group level, picture level, slice level, or tile group level.

[0198] Clause 70. A method according to any one of clauses 1-68, wherein an indication of whether and / or how the intra-frame mode is generated based on the codec information 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.

[0199] Clause 71. A method according to any one of clauses 1-68, wherein the indication of whether and / or how the intra-frame mode is generated based on the codec information is included in one of the following: a prediction block (PB), a transform block (TB), a codec block (CB), a prediction unit (PU), a transform unit (TU), a codec unit (CU), a virtual pipeline data unit (VPDU), a codec tree unit (CTU), a CTU row, a slice, a tile, a sub-picture; or an area containing more than one sample or pixel.

[0200] Clause 72. The method according to any one of clauses 1-68 further includes: determining whether and / or how to generate the intra-frame mode based on the codec information of the video unit, the codec information including at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[0201] Clause 73. A method of video processing, comprising: for conversion between a video unit of a video and a bitstream of the video, determining at least one codec tool for which screen content codec for the video unit is to be disabled; and performing the conversion based on the determination.

[0202] Clause 74. A method according to clause 73, wherein at least one of the coding tools is selected from the following: decoder-side intra mode derivation (DIMD), a variant of DIMD, template-based intra mode derivation (TIMD), a variant of TIMD, overlapped block motion compensation (OBMC), a variant of OBMC, local illumination compensation (LIC), a variant of LIC, multiple hypothesis prediction (MHP), a variant of MHP, combined intra / inter prediction mode (CIIP), a variant of CIIP, a fusion process of two predictions, deblocking, a variant of deblocking, adaptive loop filtering (ALF), a variant of ALF, screen content coding (SCC), a variant of SCC, bilateral filtering, or a variant of bilateral filtering.

[0203] Clause 75. A method according to clause 73, wherein high-level syntax is indicated at one of the following levels to indicate whether at least one codec tool is disabled for encoding and decoding of the screen content: sequence parameter set (SPS), picture parameter set (PPS), picture header (PH), or sequence header (SH).

[0204] Clause 76. A method according to any of clauses 73-75, wherein an indication of whether and / or how to determine the at least one codec tool to be disabled is indicated at one of: a sequence level, a picture group level, a picture level, a slice level, or a tile group level.

[0205] Clause 77. A method according to any one of clauses 73-75, wherein an indication of whether and / or how to determine the at least one codec tool to be disabled 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.

[0206] Clause 78. A method according to any of clauses 73-75, wherein an indication of whether and / or how to determine the at least one codec tool to be disabled is included in one of the following: a prediction block (PB), a transform block (TB), a codec block (CB), a prediction unit (PU), a transform unit (TU), a codec unit (CU), a virtual pipeline data unit (VPDU), a codec tree unit (CTU), a CTU row, a slice, a tile, a sub-picture, or a region containing more than one sample or pixel.

[0207] Clause 79. The method according to any one of clauses 73-75 further includes: determining whether and / or how to determine at least one codec tool to be disabled based on the codec information of the video unit, the codec information including at least one of the following: block size, color format, single tree and / or dual tree partitioning, color component, slice type, or picture type.

[0208] Clause 80. The method of any of clauses 1-79, wherein the converting comprises encoding the video unit into the bitstream.

[0209] Clause 81. The method of any of clauses 1-79, wherein the converting comprises decoding the video unit from the bitstream.

[0210] Clause 82. 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 of clauses 1-81.

[0211] Clause 83. A non-transitory computer-readable storage medium storing instructions that cause a processor to perform the method of any of clauses 1-81.

[0212] Item 84. A non-transitory computer-readable recording medium storing a bitstream of a video, the bitstream of the video being generated by a method performed by a device for video processing, wherein the method comprises: generating an intra-frame mode for a video unit based on codec information associated with the video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; and generating the bitstream based on the generated intra-frame mode.

[0213] Item 85. A method for storing a bitstream of a video, comprising: generating an intra-frame mode for a video unit based on codec information associated with the video unit of the video, wherein the video unit is an intra-frame template matching (TM) codec block, or the video unit is an intra-frame copy block (IBC) codec block; generating the bitstream based on the generated intra-frame mode; and storing the bitstream in a non-transitory computer-readable recording medium.

[0214] Item 86. A non-transitory computer-readable medium storing a bitstream of a video, the bitstream of the video being generated by a method performed by a device for video processing, wherein the method comprises: determining at least one codec tool for which screen content encoding and decoding of a video unit of the video will be disabled; and generating the bitstream based on the determination.

[0215] Clause 87. A method for storing a bitstream of a video, comprising: determining at least one codec tool for which screen content encoding and decoding of a video unit of the video is to be disabled; generating the bitstream based on the determination; and storing the bitstream in a non-transitory computer-readable recording medium. Example Device

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

[0217] It should be understood that Fig.23 The computing device 2300 shown in the figure 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.

[0218] like Fig.23 As shown, computing device 2300 includes a general computing device 2300. Computing device 2300 may include at least one or more processors or processing units 2310, memory 2320, storage unit 2330, one or more communication units 1140, one or more input devices 2350, and one or more output devices 2360.

[0219] In some embodiments, the computing device 2300 can be implemented as any user terminal or server terminal with computing power. 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 the computing device 2300 can support any type of interface to the user (such as a "wearable" circuit device, etc.).

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

[0221] The computing device 2300 typically includes various computer storage media. Such media can be any media accessible by the computing device 2300, including but not limited to volatile media and non-volatile media, or removable media and non-removable media. The memory 2320 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 2330 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 2300.

[0222] The computing device 2300 may also include additional removable / non-removable storage media, volatile / non-volatile storage media. Fig.23 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.

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

[0224] Input device 2350 may be one or more of various input devices, such as a mouse, keyboard, trackball, voice input device, etc. Output device 2360 may be one or more of various output devices, such as a display, speaker, printer, etc. With the aid of communication unit 2340, computing device 2300 may also communicate with one or more external devices (not shown), such as storage devices and display devices, and computing device 2300 may also communicate with one or more devices that enable a user to interact with computing device 2300, or any device that enables computing device 2300 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).

[0225] In some embodiments, some or all components of the computing device 2300 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 infrastructure may provide services through a shared data center, although they appear as a single access point for users. Therefore, the cloud computing architecture may be used to provide the 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.

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

[0227] In an example embodiment performing video encoding, input device 2350 may receive video data as input 2370 to be encoded. The video data may be processed by, for example, video codec module 2325 to generate an encoded bitstream. The encoded bitstream may be provided as output 2380 via output device 2360.

[0228] In an example embodiment performing video decoding, input device 2350 may receive an encoded bitstream as input 2370. The encoded bitstream may be processed by, for example, video codec module 2325 to generate decoded video data. The decoded video data may be provided as output 2380 via output device 2360.

[0229] 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 video processing method, comprising: For conversion between a video unit of a video and a bitstream of the video, generating an intra mode for the video unit based on codec information associated with the video unit, wherein the video unit is an intra template matching (TM) codec block, or the video unit is an intra copy block (IBC) codec block; and The converting is performed based on the generated intra mode.

2. The method of claim 1 , wherein generating the intra-mode comprises: The intra mode is generated based on the codec information of the intra TM codec block.

3. The method of claim 2, wherein the generated intra mode is derived based on a gradient of the intra TM codec block. 4 . The method of claim 3 , wherein based on the gradient, a converted or mapped intra mode is generated and stored as the intra mode of the intra TM codec block.

5. The method of claim 2, wherein the generated intra mode is derived based on a block vector of the intra TM codec block. The method according to claim 5 , wherein the direction of the block vector is utilized.

7. The method of claim 5, wherein based on the direction or angle of the block vector, a converted or mapped intra mode is generated and stored as the intra mode of the intra TM codec block. The method according to claim 2 , wherein the generated intra-mode is derived based on a mapping table.

9. The method of claim 8, wherein the mapping table comprises at least one entry based on a block vector of the intra TM coded block.

10. The method of claim 1, wherein the generated intra-mode of the intra TM codec block is stored in a buffer. The method according to claim 10 , wherein a prediction block of the intra TM codec block is not generated based on the generated intra mode.

12. The method of claim 10, wherein the stored intra mode of the intra TM codec block is used for coding of a subsequent block.

13. The method of claim 1, wherein the intra TM based prediction block is combined with the second prediction block.

14. The method of claim 13, wherein the intra TM based prediction block is combined with a decoder side intra mode derived (DIMD) prediction block.

15. The method of claim 13, wherein the intra TM based prediction block is combined with a template based intra mode derivation (TIMD) prediction block.

16. The method of claim 13, wherein the intra TM based prediction block is combined with a multiple hypothesis prediction (MHP) prediction block.

17. The method of claim 13, wherein the intra TM based prediction block is combined with an intra block copy (IBC) prediction block.

18. The method according to claim 1, wherein the block vector of the intra TM codec block is used for coding of a subsequent block, wherein the coding of the subsequent block comprises at least one of the following processes: IBC forecast list generation, TIMD-based pattern export, TIMD-based prediction derivation, or DIMD-based mode export, DIMD-based prediction export.

19. The method of claim 18, wherein the IBC prediction list generation comprises at least one of the following: Advanced Motion Vector Prediction (AMVP) list for regular IBC mode, A merged list for regular IBC mode, AMVP list for IBC-TM mode, A merged list for IBC-TM mode, AMVP list for IBC merge mode with motion vector difference (MMVD) mode, The merged list for IBC-MMVD mode, AMVP list for rebuilding the reordered IBC (RRIBC), or Consolidated list for RRIBC.

20. The method of claim 1, wherein intra TM is used for chroma blocks in at least one of: single tree or dual tree.

21. The method of claim 20, wherein in the dual tree, block vectors of chroma intra TM are derived based on block vectors of corresponding luma intra TM.

22. The method of claim 20, wherein in the dual tree, the intra TM flag of the chroma block is inherited from the corresponding luma block.

23. The method of claim 20, wherein in the dual tree, if the chroma block is coded as an intra distribution matching (INTRA_DM) mode and the luma block is coded as an intra TM mode, the chroma is coded as an intra TM mode.

24. The method of claim 20, wherein in the single tree, block vectors of chroma intra TMs are derived based on block vectors of corresponding luma intra TMs.

25. The method of claim 20, wherein in the single tree, if the chroma block is coded as INTRA_DM mode and the luma block is coded as intra TM mode, the chroma block is coded as intra TM mode based on a block vector of the luma block.

26. The method of claim 20, wherein in the single tree, chroma intra TM and luma intra TM share the same intra TM syntax.

27. The method of claim 20, wherein in the single tree, searching for block vectors for intra TM coded blocks considers costs from both luma blocks and chroma blocks.

28. The method of claim 1, wherein generating the intra-mode comprises: The intra mode is generated based on codec information of a reference block of the intra TM codec block.

29. The method of claim 28, wherein the reference block is derived based on a block vector of the intra TM coded block.

30. The method of claim 28, wherein the generated intra-mode of the intra TM codec block is derived based on at least one of: the intra mode of the reference block, The gradient of the reference block, the prediction mode of the reference block, or The codec information of the codec unit covering the reference block.

31. The method of claim 28, wherein if a coding unit (CU) covering the reference block includes a plurality of candidate blocks, one intra mode among a plurality of intra modes is selected for the generated intra mode.

32. The method of claim 31, wherein the selected rule is based on prediction modes of the plurality of candidate blocks.

33. The method of claim 31, wherein the selected rule is based on a predefined candidate block checking order.

34. The method of claim 31, wherein a rule for the selection is based on positions of the plurality of candidate blocks relative to the intra TM block.

35. The method of claim 31 , wherein the selected rule is based on template cost.

36. The method of claim 28, wherein if at least one of the reference block or the CU covering the reference block is not encoded or decoded by one of: intra mode, IBC mode or intra TM mode, planar mode is used as the generated intra mode.

37. The method according to claim 1, wherein the generated intra mode of the intra TM codec block is used for codec of a subsequent block, wherein the codec of the subsequent block comprises at least one of the following processes: Most Probable Mode (MPM) list generation, TIMD mode export, TIMD prediction export, DIMD-based mode export, Based on DIMD prediction export, Fusion-based mode export, Fusion-based prediction derivation, or Deblocking filter.

38. The method of claim 37, wherein the MPM list generation comprises at least one of the following: List of MPMs for regular intra modes, MPM list for Geometry Partitioning Mode (GPM)-Intra-Inter mode, MPM list for spatial GPM intra mode, MPM list for Multi-Linear Regression Intra Prediction (MIP) mode, List of MPMs for TIMD mode, the first MPM list for the video codec, or Second MPM list for video codec.

39. The method of claim 37, wherein the deblocking filter comprises a deblocking strength, or The deblocking filter includes a filter strength of the deblocking process.

40. The method of claim 1, wherein the IBC based prediction block is combined with a second prediction block.

41. The method of claim 40, wherein the IBC based prediction block is combined with a DIMD prediction block.

42. The method of claim 40, wherein the IBC based prediction block is combined with a TIMD prediction block.

43. The method of claim 40, wherein the IBC based prediction block is combined with a MHP prediction block.

44. The method of claim 40, wherein the IBC based prediction block is combined with an intra TM prediction block.

45. The method of claim 1, wherein the generated intra-mode is generated for the BIC codec block and is used for at least one of: intra-mode coding or intra-mode prediction of a subsequent block.

46. ​​The method of claim 1, wherein generating the intra-mode comprises: The intra mode is generated based on codec information of a reference block of the IBC codec block.

47. The method of claim 46, wherein the reference block is derived based on a block vector of the IBC codec block.

48. The method of claim 46, wherein the generated intra-mode of the IBC codec block is derived based on at least one of: the intra mode of the reference block, The gradient of the reference block, the prediction mode of the reference block, or The codec information of the codec unit covering the reference block.

49. The method of claim 46, wherein if a CU covering the reference block includes a plurality of candidate blocks, one intra mode among a plurality of intra modes is selected for the generated intra mode.

50. The method of claim 49, wherein the selected rule is based on prediction modes of the plurality of candidate blocks.

51. The method of claim 49, wherein the selected rule is based on a predefined candidate block checking order.

52. The method of claim 49, wherein a rule for the selection is based on a position of the plurality of candidate blocks relative to the intra TM block.

53. The method of claim 49, wherein the selected rule is based on template cost.

54. The method of claim 46, wherein if at least one of the reference block or the CU covering the reference block is not encoded or decoded by at least one of: intra mode, IBC mode or intra TM mode, then planar mode is used as the generated intra mode.

55. The method of claim 1, wherein generating the intra-mode comprises: The intra mode is generated based on the codec information of the IBC codec block.

56. The method of claim 55, wherein the generated intra-mode is derived based on a block vector of the IBC codec block.

57. The method of claim 56, wherein the direction of the block vector is utilized.

58. The method of claim 56, wherein based on the direction or angle of the block vector, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

59. The method of claim 55, wherein the generated intra-mode is derived based on a mapping table.

60. The method of claim 59, wherein the mapping table includes at least one entry based on a block vector of the IBC codec block.

61. The method of claim 55, wherein the generated intra-mode is derived based on a gradient of the IBC codec block.

62. The method of claim 61, wherein based on the gradient, a converted or mapped intra-mode is generated and stored as the intra-mode of the IBC codec block.

63. The method of claim 1, wherein the generated intra-mode of the IBC codec block is stored in a buffer.

64. The method of claim 63, wherein a prediction block of the IBC codec block is not generated based on the generated intra mode.

65. The method of claim 63, wherein the stored intra-mode of the IBC codec block is used for coding of a subsequent block.

66. The method of claim 1, wherein the generated intra-mode of the IBC codec block is used for coding of a subsequent block, wherein the coding of the subsequent block comprises at least one of the following processes: Most Probable Mode (MPM) list generation, TIMD mode export, TIMD prediction export, DIMD-based mode export, Based on DIMD prediction export, Fusion-based mode export, Fusion-based prediction derivation, or Deblocking filter.

67. The method of claim 66, wherein the MPM list generation comprises at least one of the following: List of MPMs for regular intra modes, MPM list for Geometry Partitioning Mode (GPM)-Intra-Inter mode, MPM list for spatial GPM intra mode, MPM list for Multi-Linear Regression Intra Prediction (MIP) mode, List of MPMs for TIMD mode, the first MPM list for the video codec, or Second MPM list for video codec.

68. The method of claim 66, wherein the deblocking filter comprises a deblocking strength, or The deblocking filter includes a filter strength of the deblocking process.

69. The method according to any one of claims 1-68, wherein the indication of whether and / or how the intra mode is generated based on the codec information is indicated in one of the following: Sequence level, Picture group level, Picture level, Stripe level, or Tile group level.

70. The method according to any one of claims 1-68, wherein whether and / or how the indication of the intra mode is generated based on the codec information is indicated in one of the following: Sequence header, Picture header, Sequence Parameter Set (SPS), Video Parameter Set (VPS), Dependent Parameter Set (DPS), Decoding Capability Information (DCI), Picture Parameter Set (PPS), Adaptive Parameter Set (APS), Strip header, or Tile group header.

71. The method according to any one of claims 1-68, wherein the indication of whether and / or how to generate the intra mode based on the codec information is included in one of the following: Prediction Block (PB), Transform Block (TB), Codec Block (CB), Prediction Unit (PU), Transformation Unit (TU), Codec Unit (CU), Virtual Pipeline Data Unit (VPDU), Codec Tree Unit (CTU), CTU line, Strips, Tile, sub-image; or An area that contains more than one sample or pixel.

72. The method of any one of claims 1-68, further comprising: Based on the codec information of the video unit, determining whether and / or how to generate the intra mode based on the codec information, wherein the codec information includes at least one of the following: Block size, Color format, Single-tree and / or dual-tree partitioning, Color components, Strip type, or Image type.

73. A method of video processing, comprising: For conversion between a video unit of a video and a bitstream of the video, determining at least one codec tool for which screen content codec for the video unit is to be disabled; as well as The converting is performed based on the determination.

74. The method of claim 73, wherein the at least one codec tool is selected from: Decoder-side intra mode derivation (DIMD), A variant of DIMD, Template-based intra mode derivation (TIMD), A variant of TIMD, Overlapped Block Motion Compensation (OBMC), Variants of OBMC, Local Illumination Compensation (LIC), Variants of LIC, Multiple Hypothesis Prediction (MHP), Variants of MHP, Combined intra / inter prediction mode (CIIP), Variants of CIIP, The fusion process of two predictions, Remove blocks, Deblocking variants, Adaptive loop filtering (ALF), A variant of ALF, Screen Content Codec (SCC), SCC variants, Bilateral filtering, or A variation of bilateral filtering.

75. The method of claim 73, wherein high-level syntax is indicated at one of the following levels to indicate whether the at least one codec tool is disabled for the screen content encoding: Sequence Parameter Set (SPS), Picture Parameter Set (PPS), Picture Header (PH), or Sequence Header (SH).

76. The method of any one of claims 73-75, wherein whether and / or how to determine the indication of the at least one codec tool to be disabled is indicated in one of: Sequence level, Picture group level, Picture level, Stripe level, or Tile group level.

77. The method of any of claims 73-75, wherein the indication of whether and / or how to determine the at least one codec tool to be disabled is indicated in one of the following: Sequence header, Picture header, Sequence Parameter Set (SPS), Video Parameter Set (VPS), Dependent Parameter Set (DPS), Decoding Capability Information (DCI), Picture Parameter Set (PPS), Adaptive Parameter Set (APS), Strip header, or Tile group header.

78. The method of any of claims 73-75, wherein the indication of whether and / or how to determine the at least one codec tool to be disabled is included in one of: Prediction Block (PB), Transform Block (TB), Codec Block (CB), Prediction Unit (PU), Transformation Unit (TU), Codec Unit (CU), Virtual Pipeline Data Unit (VPDU), Codec Tree Unit (CTU), CTU line, Strips, Tile, sub-image, or An area that contains more than one sample or pixel.

79. The method of any one of claims 73-75, further comprising: Determine whether and / or how to determine the at least one codec tool to be disabled based on codec information of the video unit, the codec information comprising at least one of the following: Block size, Color format, Single-tree and / or dual-tree partitioning, Color components, Strip type, or Image type.

80. The method of any one of claims 1-79, wherein the converting comprises encoding the video unit into the bitstream.

81. The method of any one of claims 1-79, wherein the converting comprises decoding the video unit from the bitstream.

82. 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-81.

83. A non-transitory computer-readable storage medium storing instructions, the instructions causing a processor to execute the method according to any one of claims 1-81.

84. A non-transitory computer-readable recording medium storing a bit stream of a video, wherein the bit stream of the video is generated by a method performed by an apparatus for video processing, wherein the method comprises: generating an intra mode for a video unit of the video based on codec information associated with the video unit, wherein the video unit is an intra template matching (TM) codec block, or the video unit is an intra copy block (IBC) codec block; and The bitstream is generated based on the generated intra mode.

85. A method for storing a bitstream of a video, comprising: Generating an intra mode for a video unit of the video based on codec information associated with the video unit, wherein the video unit is an intra template matching (TM) codec block, or the video unit is an intra copy block (IBC) codec block; generating the bitstream based on the generated intra-mode; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

86. A non-transitory computer-readable 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 at least one codec tool for which screen content codecs for a video unit of the video are to be disabled; as well as The bitstream is generated based on the determination.

87. A method for storing a bitstream of a video, comprising: determining at least one codec tool for which screen content codecs for a video unit of the video are to be disabled; generating the bitstream based on the determination; as well as The bit stream is stored in a non-transitory computer-readable recording medium.

Images