Method and device for video processing and medium

Abstract

Embodiments of the present disclosure provide a solution for video processing. A method for video processing is presented. The method includes, for a conversion between a video unit of a video and a bitstream of the video unit, deriving a block vector for a direct block vector (DBV) mode of a chroma block of the video unit based on one of: a block vector of a luma block at a predefined location, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; and performing a conversion based on the block vector of the DBV mode for the chroma block.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to video processing techniques, and more particularly, to a direct block vector mode for chroma prediction in image / video codecs. Background Art

[0002] Digital video capabilities are now being used in every aspect of our lives. For video encoding and decoding, various video compression technologies have been proposed, including 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), and Versatile Video Codec (VVC). However, there is a general desire to further improve the encoding and decoding efficiency of video encoding and decoding technologies. Summary of the Invention

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

[0004] In a first aspect, a method for video processing is provided. The method includes: for conversion between a video unit and a bitstream of the video unit, deriving a block vector in a direct block vector (DBV) mode for a chroma block of the video unit based on one of the following: a block vector for a luma block at a predefined position, a block vector for a luma sub-block with NxN granularity, where N is an integer, or a list of block vector candidates; and performing conversion based on the block vector in the DBV mode for the chroma block. The method according to the first aspect of the present disclosure can improve codec efficiency and codec performance.

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

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

[0007] In a fourth aspect, another non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by an apparatus for video processing. The method includes: deriving a block vector in a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of the following: a block vector for a luma block at a predefined position, a block vector for a luma sub-block at an NxN granularity, where N is an integer, or a list of block vector candidates; and generating a bitstream based on the block vector in the DBV mode for the chroma block.

[0008] In a fifth aspect, a method for storing a bitstream of a video is provided. The method includes: deriving a block vector of a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of the following: a block vector of a luma block at a predefined position, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; generating a bitstream based on the block vector of the DBV mode for the chroma block, and storing the bitstream in a non-transitory computer-readable medium.

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

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

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

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

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

[0014] Figure 4 Graphs showing the effect of the slope adjustment parameter "u". Left: Model created with the current CCLM. Right: Model updated as proposed;

[0015] Figure 5 shows the neighboring blocks (L, A, BL, AR, AL) used for the derivation of the general MPM list;

[0016] Figure 6 shows the adjacent reconstructed samples used for DIMD chroma mode;

[0017] Figure 7 The intra-frame template matching search area used is shown;

[0018] Figure 8 The division method for angle mode is shown;

[0019] Figure 9The expanded MRL candidate list is shown;

[0020] Figure 10 The spatial portion of the convolution filter is shown;

[0021] Figure 11 shows the reference region (with its filling) used to derive the filter coefficients;

[0022] Figure 12 Four Sobel-based gradient modes for GLM are shown;

[0023] Figure 13 The template area is shown;

[0024] Figure 14 The current CTU processing order and its available reference samples in the current CTU and the left CTU are shown;

[0025] Figure 15A A diagram showing BV adjustment for horizontal flipping is shown;

[0026] Figure 15B A diagram showing BV adjustment for vertical flipping is shown;

[0027] Figure 16 The residual encoding and decoding passes for a transform skip block are shown;

[0028] Figure 17 shows an example of a block being encoded and decoded in palette mode;

[0029] Figure 18 Sub-block based index map scanning for a palette is shown, on the left for horizontal scanning and on the right for vertical scanning;

[0030] Figure 19 Shown is a decoding flow chart using ACT;

[0031] Figure 20 The intra-frame template matching search area used is shown;

[0032] Figure 21 Five positions in the reconstructed brightness samples are shown;

[0033] Figure 22 The prediction process of DBV mode is shown;

[0034] Figure 23 The low-frequency non-separable transform (LFNST) process is shown;

[0035] Figure 24 The SBT position, type and transformation type are shown;

[0036] Figure 25The ROI for LFNST16 is shown;

[0037] Figure 26 The ROI for LFNST8 is shown;

[0038] Figure 27 Discontinuity measurements are shown;

[0039] Figure 28 The proposed design using NSPT and LFNST is shown;

[0040] Figure 29 An example of a co-located luma block with a current chroma block in a 4:2:0 color format is shown;

[0041] Figure 30 An example of a co-located luma block with a current chroma block in a 4:2:0 color format is shown;

[0042] Figure 31 An example of a validation check rule for determining a valid block vector is shown;

[0043] Figure 32 A flowchart showing a method for video processing according to an embodiment of the present disclosure is shown; and

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

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

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

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

[0048] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment is required to include that 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, it is intended that such feature, structure, or characteristic, whether or not explicitly described, be applicable to other embodiments and that it is within the knowledge of those skilled in the art to apply such feature, structure, or characteristic.

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

[0050] The terms used herein are used only for the purpose of describing specific embodiments and are not intended to limit the example 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 "comprise," "including," "having," "including," and / or "comprising" 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. Sample Environment

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

[0052] The 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 for receiving video data from a video content provider, a computer graphics system for generating video data, and / or a combination thereof.

[0053] 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 sequence of bits that form a coded representation of the video data. The bitstream may include coded pictures and associated data. The coded pictures are coded representations of the pictures. The associated data may include sequence parameter sets, picture parameter sets, and other syntax structures. The I / O interface 116 may include a modulator / demodulator and / or a transmitter. The coded video data may be directly transmitted to the destination device 120 via the network 130A via the I / O interface 116. The coded video data may also be stored on a storage medium / server 130B for access by the destination device 120.

[0054] 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 source device 110 or storage medium / server 130B. The video decoder 124 may decode the encoded video data. The display device 122 may display the decoded video data to a user. The display device 122 may be integrated with the destination device 120, or may be external to the destination device 120, the destination device 120 being configured to interface with an external display device.

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

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

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

[0058] In some embodiments, the video encoder 200 may include a segmentation 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 cache 213 and an entropy coding 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.

[0059] 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 in which at least one reference picture is the picture in which the current video block is located.

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

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

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

[0063] 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 cache 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 cache 213 other than the picture associated with the current video block.

[0064] 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, "P slices" and "B slices" may refer to portions of a picture consisting of macroblocks that are independent of macroblocks in the same picture.

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

[0066] 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 multiple reference indices and multiple motion vectors, the multiple reference indices indicating multiple reference pictures in list 0 and list 1 containing multiple reference video blocks, and the multiple motion vectors indicating multiple spatial displacements between the multiple reference video blocks and the current video block. The motion estimation unit 204 may output the multiple reference indices and multiple motion vectors for the current video block as motion information for the current video block. The motion compensation unit 205 may generate a predicted video block for the current video block based on the multiple reference video blocks indicated by the motion information of the current video block.

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

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

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

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

[0071] The intra-frame prediction unit 206 can perform intra-frame prediction on the current video block. When the intra-frame prediction unit 206 performs intra-frame prediction on the current video block, the intra-frame prediction unit 206 can 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 can include a predicted video block and various syntax elements.

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

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

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

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

[0076] The inverse quantization unit 210 and the inverse transform unit 211 may apply inverse quantization and inverse transform, respectively, to the transform coefficient video block 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.

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

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

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

[0080] Video decoder 300 may be configured to perform any or all of the techniques of this disclosure. Figure 3 In the example of FIG, video decoder 300 includes multiple functional components. The techniques described in this disclosure can be shared among 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.

[0081] exist Figure 3 In the example of FIG. 3 , 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, 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.

[0082] The entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded blocks of video data). 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, which motion information includes motion vectors, motion vector precision, reference picture list indexes, and other motion information. The motion compensation unit 302 can determine such information, for example, by performing AMVP and Merge mode. AMVP is used, which includes deriving several most likely candidates based on data from adjacent PBs and reference pictures. The motion information typically includes horizontal motion vector displacement values ​​and vertical motion vector displacement values, one or two reference picture indexes, and in the case of prediction regions in B slices, 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 spatially neighboring blocks or temporally neighboring blocks.

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

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

[0085] The motion compensation unit 302 can use at least part of the syntax information to determine the size of the blocks used to encode the (multiple) frames and / or (multiple) slices of the encoded video sequence, partition information describing how each macroblock of the 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 coded block, and other information used to decode the encoded video sequence. As used herein, in some aspects, "slice" can refer to a data structure that can be decoded independently of other slices of the same picture in terms of entropy coding and decoding, signal prediction, and residual signal reconstruction. A slice can be an entire picture or a region of a picture.

[0086] The intra prediction unit 303 can 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.

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

[0088] Some exemplary embodiments of the present disclosure are described in detail below. It should be noted that the section headings used in this document are for ease of understanding and do not limit the embodiments disclosed in a section to that section. In addition, although some embodiments are described with reference to a multifunctional video codec 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 for de-encoding will be implemented by the decoder. In addition, the term video processing includes video encoding or compression, video decoding or decompression, and video transcoding, in which video pixels are represented from one compression format to another compression format or at a different compression bit rate. 1. Brief Overview The present disclosure relates to video coding technology. Specifically, it relates to chrominance prediction in image / video coding. It can be applied to existing video coding standards such as HEVC and VVC. It is also applicable to future video coding standards or video codecs. 2. Introduction Video codec standards evolve primarily through 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, H.264 / MPEG-4 Advanced Video Codec (AVC), and H.265 / HEVC. Since H.262, video codec standards have been based on a hybrid video codec architecture that utilizes temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. JVET meetings are held quarterly. The new video codec standard was officially named the Versatile Video Codec (VVC) at the JVET meeting in April 2018, and the first version of the VVC Test Model (VTM) was released at that time. The VVC working draft and the VTM test model are updated after each meeting. The VVC project achieved technical completion (FDIS) at the July 2020 meeting. Intra-frame prediction In intra prediction, the minimum chroma intra prediction unit (SCIPU) constraint in VVC is removed. In addition, the VPDU constraint used to reduce CCLM prediction delay is also removed. Multi-Model LM (MMLM) The CCLM included in VVC is extended by adding three multi-model LM (MMLM) modes (JVET-D0110). In each MMLM mode, the reconstructed neighboring samples are classified into two categories using a threshold value, which is the average value of the luminance reconstruction neighboring samples. The linear model for each category is derived using the least mean square (LMS) method. For the CCLM mode, the LMS method is also used to derive the linear model. Slope adjustment is applied to the cross-component linear model (CCLM) and multi-model LM prediction. The adjustment is a linear function that maps the luminance value to the chrominance value according to the center point tilt determined by the average luminance value of the reference sample. 2.1.1.1. CCLM Slope Adjustment CCLM uses a 2-parameter model to map luma values ​​to chroma values. The slope parameter "a" and the bias parameter "b" define the following mapping: chromaVal=a*lumaVal+b. The adjustment to the slope parameter "u" is signaled to update the model to the following form: chromaVal=a'*lumaVal+b' in a'=a+u b'=b–u*y r . With this choice, the mapping function is centered around the value y with the brightness r The average value of the reference brightness samples used in model creation is y r , in order to provide meaningful modifications to the model. The following image illustrates this process. Figure 4 is a graphical representation of the effect of the slope adjustment parameter "u", where the left graph shows the model created with the current CCLM and the right graph shows the updated model as proposed. Implementation The slope adjustment parameter is provided as an integer between -4 and 4 (inclusive) and is signaled in the bitstream. The unit of the slope adjustment parameter is 1 / 8 of the chroma sample value for each luma sample value (for 10-bit content). Adjustments can be made to CCLM models that use reference samples above and to the left of the block ("LM_CHROMA_IDX" and "MMLM_CHROMA_IDX"), but not for "one-sided" mode. This choice is based on a trade-off between codec efficiency and complexity. When slope adjustment is applied for a multi-mode CCLM model, two models may be adjusted and thus up to two slope updates are signaled for a single chroma block. Encoder Method The proposed encoder method performs a SATD-based search for the optimal value of the slope update for Cr and a similar SATD-based search for Cb. If either results as a non-zero slope adjustment parameter, the combined slope adjustment pair (SATD-based update for Cr, SATD-based update for Cb) is included in the list of RD checks for TU. Gradient PDPC In VVC, for a few scenes, PDPC may not be applied due to the unavailability of secondary reference samples. In these cases, the gradient-based PDPC extended from the horizontal / vertical mode is applied (JVET-Q0391). The PDPC weights (wT / wL) and nScale parameters used to determine the attenuation of PDPC weights with distance from the left / top boundary are set equal to the corresponding parameters in the horizontal / vertical mode, respectively. When the secondary reference samples are at fractional sample positions, bilinear interpolation is applied. 2.1.3. Secondary MPM Secondary MPM lists are introduced as described in JVET-D0114. The existing primary MPM (PMPM) list consists of 6 entries, and the secondary MPM (SMPM) list includes 16 entries. First, a general MPM list with 22 entries is constructed, and then the first 6 entries of the general MPM list are included in the PMPM list, and the remaining entries form the SMPM list. The first entry in the general MPM list is the plane mode. The remaining entries are Figure 5 The frame consists of the intra modes of the left (L), above (A), lower left (BL), upper right (AR) and upper left (AL) neighboring blocks shown in the figure, the directional modes with increasing offsets from the first two available directional modes of the neighboring blocks, and the default mode. If the CU block is vertically oriented, the order of neighboring blocks is A, L, BL, AR, AL; otherwise, it is L, A, BL, AR, AL. First the PMPM flag is parsed, if it is equal to 1, then the PMPM index is parsed to determine which entry of the PMPM list is selected, otherwise the SPMPM flag is parsed to determine whether to parse the SMPM index or the rest of the modes. Figure 5 Neighboring blocks (L, A, BL, AR, AL) used to derive the common MPM list are shown. 2.1.4. Reference Sample Interpolation and Smoothing for Intra Prediction As described in JVET-D0119, a 6-tap cubic interpolation filter is used instead of a 4-tap cubic interpolation filter to derive the prediction samples from the reference samples. For reference sample filtering, a 6-tap Gaussian filter is applied for larger blocks (W>=32 and H>=32), otherwise the existing VVC 4-tap Gaussian interpolation filter is applied. Extended intra reference samples are derived using a 4-tap interpolation filter instead of nearest neighbor rounding. 2.1.5. Decoder-side Intra Mode Derivation (DIMD) When DIMD is applied, two intra modes are derived from the reconstructed neighboring samples, and these two predictions are combined with the planar mode prediction, where the weights are derived from the gradients as described in JVET-00449. The division operation in the weight derivation is performed using the same lookup table (LUT) based integration scheme used by CCLM. For example, the division operation in the orientation calculation Orient=G y / G x It is calculated using the following LUT-based scheme: x=Floor(Log2(Gx)) normDiff=((Gx<<4)>>x)&15 x+=(3+(normDiff!=0)?1:0) Orient=(Gy*(DivSigTable[normDiff]|8)+(1<<(x-1)))>>x in DivSigTable

[16] ={0,7,6,5,5,4,4,3,3,2,2,1,1,1,1,0}. The derived intra modes are included in the preliminary list of intra most probable modes (MPMs), so the DIMD process is performed before the MPM list is built. The preliminary derived intra modes of a DIMD block are stored with the block and are used to build the MPM lists of neighboring blocks. 2.1.5.1.DIMD Chroma Mode The DIMD colorimetric mode uses the DIMD derivation method based on Figure 6 The neighboring reconstructed Y, Cb, and Cr samples in the second neighboring row and column are shown to derive the chroma intra prediction mode for the current block. Figure 6 Sample neighborhood reconstruction for DIMD chroma mode is shown. Specifically, horizontal and vertical gradients are calculated for each co-located reconstructed luma sample and reconstructed Cb and Cr samples of the current chroma block to construct the HoG. The intra prediction mode with the largest histogram magnitude value is then used to perform chroma intra prediction for the current chroma block. When the intra prediction mode derived from the DIMD chroma mode is the same as the intra prediction mode derived from the DM mode, the intra prediction mode with the second largest histogram magnitude value is used as the DIMD chroma mode. A CU level flag is signaled to indicate whether the proposed DIMD chroma mode is applied. 2.1.6. Fusion of Chroma Intra Prediction Modes The DM mode and the four default modes can be combined with the MMLM_LT mode as follows: pred=(w0*pred0+w1*pred1+(1<<(shift-1)))>>shift Where pred0 is the prediction value obtained by applying the non-LM mode, pred1 is the prediction value obtained by applying the MMLM_LT mode, and pred is the final prediction value of the current chroma block. The two weights w0 and w1 are determined by the intra prediction mode of the adjacent chroma blocks, and shift is set to be equal to 2. Specifically, when the upper and left adjacent blocks are both coded and decoded in LM mode, {w0, w1} = {1, 3}; when the upper and left adjacent blocks are both coded and decoded in non-LM mode, {w0, w1} = {3, 1}; otherwise, {w0, w1} = {2, 2}. For syntax design, if non-LM mode is selected, a flag is signaled to indicate whether merging is applied. This method is only applicable to I slices. 2.1.7. Intra-frame template matching Intra Template Matching (Intra TMP) is a special intra prediction mode that copies the best prediction block from the reconstructed portion of the current frame, whose L-shaped template matches the current template. For a predefined search range, the encoder searches for the template most similar to the current template in the reconstructed portion of the current frame and uses the corresponding block as the prediction block. The encoder then signals the use of this mode, and the same prediction operation is performed on the decoder side. The prediction signal is obtained by combining the L-shaped causal neighbor of the current block with Figure 7 The search area is generated by matching another block in a predefined search area. The search area consists of the following components: R1: Current CTU R2: Upper left CTU R3: Upper CTU R4: left CTU. The sum of absolute differences (SAD) is used as the cost function. In each region, the decoder searches for the template with the minimum SAD relative to the current template and uses its corresponding block as the prediction block. The dimensions of all regions (SearchRange_w, SearchRange_h) are set proportionally to the block dimensions (BlkW, BlkH) so that each pixel has a fixed number of SAD comparisons. 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. Figure 7 The matching search area used within the template is shown. The intra template matching tool is enabled for CUs with size less than or equal to 64 in width and height. The maximum CU size for intra template matching is configurable. When DIMD is not used for the current CU, the intra template matching prediction mode is signaled at the CU level through a dedicated flag. 2.1.8. Fusion for Template-based Intra Mode Derivation (TIMD) For each intra prediction mode in the MPM, the SATD between the predicted and reconstructed samples of the template is calculated. The first two intra prediction modes with the smallest SATD are selected as TIMD modes. These two TIMD modes are fused with weights after applying the PDPC process, and such weighted intra prediction is used to encode and decode the current CU. Position-dependent intra prediction combining (PDPC) is included in the derivation of TIMD modes. The costs of the two selected modes are compared with the threshold. In the test, a cost factor of 2 is applied as follows: costMode2<2*costMode1. If this condition is true, fusion is applied, otherwise only mode 1 is used. The weight of a pattern is calculated from its SATD cost as follows: weight1=costMode2 / (costMode1+costMode2) weight2=1-weight1. The division operation is performed using the same lookup table (LUT) based integration scheme used by CCLM. 2.1.9. Combination of CIIP with TIMD and TM Merge In CIIP mode, prediction samples are generated by weighting the inter prediction signal predicted using CIIP-TM Merge candidates and the intra prediction signal predicted using TIMD-derived intra prediction modes. This method is only applied to codec blocks with an area less than or equal to 1024. The TIMD derivation method is used to derive intra prediction modes in CIIP. Specifically, the intra prediction mode with the smallest SATD value in the TIMD mode list is selected and mapped to one of the 67 conventional intra prediction modes. Furthermore, if the derived intra prediction mode is an angular mode, it is also proposed to modify the weights for both tests (wIntra, wInter). For near-horizontal modes (2 <= angular mode index < 34), as Figure 8 The current block shown in (a) is divided vertically, for the near vertical mode (34 <= angle mode index <= 66), as shown in FIG. Figure 8 The current block shown in (b) is divided horizontally. (wIntra, wInter) for different sub-blocks are shown in Table 2-1. Table 2-1. Modified weights used for angle mode. Sub-block index (wIntra, wInter) 0 (6,2) 1 (5,3) 2 (3,5) 3 (2,6) Using CIIP-TM, a CIIP-TM Merge candidate list is constructed for CIIP-TM mode. Merge candidates are refined by template matching. CIIP-TM Merge candidates are also reordered into regular Merge candidates by the ARMC method. The maximum number of CIIP-TM Merge candidates is equal to 2. 2.1.10. Extended Multiple Reference Line (MRL) List The MRL list in VVC is extended to include more reference lines for intra prediction. The extended reference line list consists of Figure 9 The row indices shown are {1, 3, 5, 7, 12}. For template-based intra mode derivation (TIMD), instead of the full MRL candidate list, only the first two reference row candidates, ie, {1, 3}, are used. Figure 9 An expanded MRL candidate list is shown. 2.1.11. Convolutional Cross-Component Intra Prediction Model In this method, a convolutional cross-component model (CCCM) is applied to predict chroma samples from reconstructed luma samples, similar to what is done in the current CCLM mode. As with CCLM, when chroma downsampling is used, the reconstructed luma samples are downsampled to match the lower resolution chroma grid. Similarly, similar to CCLM, there is an option to use a single model or a multi-model variant of CCCM. The multi-model variant uses two models, one model is derived for samples above the average luminance reference value, and the other model is derived for the remaining samples (following the principles of CCLM design). The multi-model CCCM mode can be selected for PUs with at least 128 available reference samples. 2.1.11.1. Convolutional Filters The convolutional 7-tap filter consists of a 5-tap plus sign-shaped spatial component, a nonlinear term, and a bias term. As described below, the input to the spatial 5-tap component of the filter consists of the center (C) luma sample, which is co-located with the chroma sample to be predicted, and its upper / north (N), lower / south (S), left / west (W), and right / east (E) neighbors. Figure 10 The spatial portion of the convolution filter is shown. The nonlinear term P is expressed as a power of two of the center luma sample C and is scaled to the content's sample value range: P=(C*C+midVal)>>bitDepth. That is, for 10-bit content, it is calculated as: P=(C*C+512)>>10. The bias term B represents a scalar offset between the input and output (similar to the offset term in CCLM) and is set to the intermediate chrominance value (512 for 10-bit content). The output of the filter is calculated as the filter coefficient c i Convolution with the input value and clipped to the range of valid chroma samples: predChromaVal=c0C+c1N+c2S+c3E+c4W+c5P+c6B. 2.1.11.2. Calculation of filter coefficients Filter coefficient c i It is calculated by minimizing the MSE between the predicted chroma samples and the reconstructed chroma samples in the reference region. Figure 11 A reference region consisting of six rows of chroma samples above and to the left of the PU is shown. The reference region extends one PU width to the right and one PU height below the PU boundary. The region is adjusted to include only available samples. The extension of the region shown in blue is needed to support the "side samples" of the cross spatial filter and is padded when in an unavailable region. MSE minimization is performed by calculating the autocorrelation matrix of the luma input and the cross-correlation vector between the luma input and the chroma output. The autocorrelation matrix is ​​decomposed by LDL, and the final filter coefficients are calculated using back-substitution. This process roughly follows the calculation of the ALF filter coefficients in ECM, however, LDL decomposition is chosen instead of Cholesky decomposition to avoid the use of square root operations. 2.1.11.3. Gradient Linear Model Compared to CCLM, GLM uses luma sample gradients to derive linear models instead of downsampled luma values. Specifically, when GLM is applied, the input to the CCLM process (i.e., downsampled luma samples L) is replaced by luma sample gradients G. The rest of CCLM (e.g., parameter derivation, linear transformation of prediction samples) remains unchanged. Figure 12 Four Sobel-based gradient modes used for the GLM are shown. C=α·G+β For signaling, when CCLM mode is enabled for the current CU, two flags are signaled separately for the Cb component and the Cr component to indicate whether GLM is enabled for each component; if GLM is enabled for a component, a syntax element is further signaled to select one of the four gradient filters used for gradient calculation. 2.1.11.4. Gradient linear model with brightness value In ECM-6.0, GLM uses the gradient of luminance samples to predict chrominance samples as: pred C (i, j) = α·G(i, j) + β, where pred C (i, j) represents the predicted value of the chrominance sample, G(i, j) represents the gradient of the corresponding reconstructed luminance sample, and based on the linear minimum mean square error (LMMSE) method, the linear model parameters α and β are derived from adjacent reconstructed samples, such as CCLM. In the test, the new GLM mode is evaluated, where the chroma samples are based on the gradient G(i,j) of the luma samples and the reconstructed value rec′ of the downsampled luma samples L (i,j) are both predicted using different parameters: pred C (i,j)=α0·G(i,j)+α1·rec′ L (i,j)+α2·midValue, The model parameters α0, α1, and α2 are derived from the six rows and columns of adjacent samples based on the LDL decomposition method, such as the CCCM model in ECM-6.0. For signaling, a flag is signaled to indicate whether GLM is enabled for both Cb and Cr components, and a syntax element indicating the gradient mode is encoded by truncation of unary codes. The original GLM mode is retained and the new GLM mode is transmitted in an additional mode by transmitting an extra flag in the bitstream. 2.1.11.5. Bitstream Signaling The use of this mode is signaled using a PU-level flag for the CABAC codec. A new CABAC context is included to provide support. When signaled, CCCM is considered a submode of CCLM. That is, if the intra prediction mode is LM_CHROMA, only the CCCM flag is signaled. 2.1.12. Template-based Multi-reference Intra Prediction In template-based multi-reference row intra prediction, instead of directly signaling the reference row and intra mode, an index to a candidate list is encoded to indicate which combination of reference row and prediction mode is used to encode the current block, and the truncated Golomb-Rice codec with a divisor of 4 is adopted to encode the selected combination from the combination list. A list of 20 candidates is constructed by combining the MPM with the reference rows {1, 3, 5, 7, 12}. Compared to regular intra-MPM, the MPM list construction is modified as follows: Planar mode is excluded from the intra prediction mode candidate list DC mode is added after 5 adjacent modes and DIMD mode Added incremental angles of ±1 to ±4 to the angle modes already included in the list. There exists 5x10=50, which is Figure 13 The SAD costs in the template area shown in are sorted in ascending order. Since the extended reference line starts from reference line 1, the area covered by reference line 0 is used for template cost calculation. The 20 combinations with the smallest SAD costs form a candidate list. 2.1.13. Intra-frame prediction fusion In the test, the intra prediction is formed by fusing the intra predictions derived from different reference lines as follows: For the angular intra prediction mode including the single mode case of TIMD and DIMD, the proposed method is implemented by transforming the angular intra prediction mode represented as p fusion =w0p line +w1p line+1 The intra prediction is derived by weighting the intra prediction obtained by multiple reference lines of p, where p line is intra prediction from the default reference line and p line+1 is the prediction from the row above the default reference row. The weights are set to w0=3 / 4 and w1=1 / 4. For TIMD mode with hybrid, p line is used for the first mode (w0=1, w1=0), and p line+1 Used in the second mode (w0=0, w1=1). For DIMD mode with hybrid, the number of prediction values ​​selected for weighted averaging is increased from 3 to 6. When angular intra mode has non-integer slope (requires reference sample interpolation) and block size is greater than 16, intra prediction fusion is applied to luma blocks, which is used with MRL and is not applied to ISP-coded blocks. PDPC is applied to the intra prediction mode that uses the reference line closest to the current block. 2.1.14. Intra-frame TMP adaptation for camera-captured content In the test, intra-frame TMP was enabled for camera-captured content with the applied acceleration method, where the search area was downsampled by a factor of 2, which reduced the template matching search by a factor of 4. After finding the best match, a second refinement process was performed, where another template matching search was performed around the best match with a reduced search range defined as min(width, height) / 2 of the current block. 2.2 Screen Content Encoding and Decoding Tools 2.2.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 encoding and decoding 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 is integer precision. The chrominance block vector is also rounded to integer precision. When combined with AMVR, the IBC mode can switch between 1-pixel and 4-pixel motion vector precision. The CU encoded and decoded by IBC is regarded as a third prediction mode in addition to the intra prediction mode or inter prediction mode. The IBC mode is applicable to CUs with a width and height that are 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 a width or height of no more 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 block is extended to all allowed block sizes. The hash key calculation for each position in the current picture is based on a 4×4 sub-block. For a current block of larger size, the hash key is determined to match the hash key of the reference block when all hash keys of all 4×4 sub-blocks match the hash keys in the corresponding reference positions. If 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 the CU level, the IBC mode is signaled using a flag, which can be signaled in 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 includes 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 prediction values, one from the left neighbor and one from the top neighbor (if IBC is used). When either neighbor is unavailable, the default block vector will be used as the prediction value. A flag is transmitted via a signal to indicate the block vector prediction value index. 2.2.1.1.IBC Reference Area To reduce memory consumption and decoder complexity, IBC in VVC only allows the reconstruction of a predefined area, which includes the area of ​​the current CTU and some areas of the left CTU. Figure 14 The reference area of ​​the IBC mode is shown, where each block represents a 64x64 luma sample unit. Depending on the location of the current codec CU position within the current CTU, the following applies: – If the current block falls into the upper left 64x64 block of the current CTU, in addition to the samples already reconstructed in the current CTU, it can also use the CPR mode 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 64x64 block of the left CTU and the reference samples in the upper right 64x64 block of the left CTU. – If the current block falls into the upper right 64x64 block of the current CTU, in addition to the samples that have been reconstructed in the current CTU, if the luma position (0, 64) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the lower left 64x64 block and the lower right 64x64 block of the left CTU; otherwise, the current block can also refer to the reference samples in the lower right 64x64 block of the left CTU. – If the current block falls into the lower left 64x64 block of the current CTU, in addition to the samples already reconstructed in the current CTU, if the luma position (64,0) relative to the current CTU has not been reconstructed, the current block can also use the CPR mode to refer to the reference samples in the upper right 64x64 block and the lower right 64x64 block of the left CTU. Otherwise, the current block can also use the CPR mode to refer to the reference samples in the lower right 64x64 block of the left CTU. If the current block falls into the lower right 64x64 block of the current CTU, it can only use the CPR mode 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.2.1.2. Interaction between IBC and other codecs The interaction between IBC mode and other inter-frame coding tools in VVC (such as paired merge candidates, history-based motion vector prediction value (HMVP), intra-frame inter-frame joint prediction (CIIP), merge mode with motion vector difference (MMVD) and geometric partition mode (GPM)) is as follows: – IBC can be used with paired merge candidates and HMVP. A new paired IBC merge candidate can be generated by averaging two IBC merge candidates. For HMVP, IBC motion is inserted into the history buffer for future reference. – IBC cannot be used in combination 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 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 derivation process of motion vectors 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 in regular MV Merge, including the use of paired Merge candidates and history-based motion prediction values, but TMVP and zero vectors are not allowed because they are invalid for IBC mode. – Separate HMVP buffers (5 candidates each) are used for traditional MV and IBC. – Block vector constraints are implemented as bitstream consistency constraints. The encoder needs to ensure that there are no invalid vectors in the bitstream, and if the merge candidate is invalid (out of range or 0), then the merge must not be used. Such bitstream consistency constraints are expressed in terms of virtual buffers as described below. – For deblocking, IBC is handled as inter mode. If the current block is coded using IBC prediction mode, AMVR does not use quarter pels; instead, AMVR is signaled to only indicate whether the MV is inter-pel or 4-integer. -Pixel (4integer-pel). - The number of IBC Merge candidates may be signaled in the slice header separately from the number of regular, sub-block, and geometry Merge candidates. The concept of a virtual buffer is used to describe the allowed reference regions and valid block vectors for IBC prediction mode. Denoting the CTU size as ctbSize, the virtual buffer ibcBuf has a width of wIbcBuf = 128x128 / ctbSize and a height of hIbcBuf = ctbSize. For example, for a CTU size of 128x128, the size of ibcBuf is also 128x128; for a CTU size of 64x64, the size of ibcBuf is 256x64; and for a CTU size of 32x32, the size of ibcBuf is 512x32. The size of VPDU is min(ctbSize, 64) in each dimension, W v =min(ctbSize, 64). The virtual IBC buffer ibcBuf is maintained as follows. – At the beginning of decoding each CTU line, flush the entire ibcBuf with an invalid value of -1. – At the start of decoding the VPDU (xVPDU, yVPDU) relative to the upper left corner of the picture, set ibcBuf[x][y]=-1, where x=xVPDU%wIbcBuf,...,xVPDU%wIbcBuf+W v - 1;y=yVPDU%ctbSize,…,yVPDU%ctbSize+W v -1. – After decoding the CU containing (x, y) relative to the top left corner of the picture, set –ibcBuf[x%wIbcBuf][y%ctbSize]=recSample[x][y]. For a block covering coordinates (x, y), if the following is true for the block vector bv = (bv[0], bv[1]), then it is valid; otherwise, it is invalid: ibcBuf[(x+bv[0])%wIbcBuf][(y+bv[1])%ctbSize] should not be equal to -1. 2.2.2. Reconstruction-Reordering IBC (RR-IBC) For IBC-encoded blocks, the Reconstruction-Reordering IBC (RR-IBC) mode is enabled. When RR-IBC is applied, the samples in the reconstructed block are flipped according to the flip type of the current block. On the encoder side, the original block is flipped before motion search and residual calculation, while the prediction block is derived without flipping. On the decoder side, the reconstructed block is flipped back to restore the original block. For blocks encoded by RR-IBC, two flipping methods (horizontal flip and vertical flip) are supported. First, for blocks encoded by IBC AMVP, a syntax flag is transmitted via a signal to indicate whether the reconstruction is flipped, and if it is flipped, another flag specifying the flip type is further transmitted via a signal. For IBC Merge, the flip type is inherited from the adjacent block and the syntax is not transmitted via a signal. Taking into account horizontal symmetry or vertical symmetry, the current block and the reference block are usually aligned horizontally or vertically. Therefore, when horizontal flipping is applied, the vertical component of BV is not transmitted via a signal and is presumed to be equal to 0. Similarly, when vertical flipping is applied, the horizontal component of BV is not transmitted via a signal and is presumed to be equal to 0. In order to better utilize the symmetry property, the flip-aware BV adjustment method is applied to refine the block vector candidates. For example, as shown in Figure 15, (x nbr ,y nbr ) and (x cur ,y cur ) represent the coordinates of the center sample points of the neighboring blocks and the current block, BV nbr and BV cur Represent the BV of the neighboring block and the current block respectively. Instead of inheriting BV directly from the neighboring block, BV cur In the case where the horizontal component of the adjacent block is coded with horizontal flipping, the motion displacement is added to BV nbr The horizontal component (expressed as BV nbr h ) is calculated, that is, BV cur h =2(x nbr -x cur )+BV nbr h Similarly, BV cur The vertical component of the adjacent block is coded with vertical flipping by adding the motion displacement to BV nbr The vertical component (expressed as BV nbr v ) is calculated, that is, BV cur v =2(y nbr -y cur )+BV nbr v . 2.2.3. Block Differential Pulse Code Modulation (BDPCM) VVC supports Block Differential Pulse Code Modulation (BDPCM) for screen content encoding 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, a flag is sent at the CU level if the CU size in terms of luma samples is less than or equal to MaxTsSize multiplied by MaxTsSize and if the CU is intra coded, where MaxTsSize is the maximum block size for which transform skip mode is allowed. This flag indicates whether regular intra codec is used or BDPCM is used. If BDPCM is used, a BDPCM prediction direction flag is sent to indicate whether the prediction is horizontal or vertical. The block is then predicted using a regular horizontal or vertical intra prediction process that samples unfiltered reference samples. The residuals are quantized and the difference between each quantized residual and its predicted value (i.e., the previously coded residual of a neighboring position, either 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 value, generating a quantized version of The modified M×N matrix in is predicted from its neighboring quantized residual values. For vertical BDPCM prediction mode, when 0≤j≤(N-1), the following is used to derive For the horizontal BDPCM prediction mode, when 0≤i≤(M-1), the following is used to derive At the decoder side, the above process is reversed to calculate Q(r i,j ), 0≤i≤M-1, 0≤j≤N-1, as follows: Dequantized residual Q -1 (Q(r i,j )) is added to the intra block prediction value to generate the reconstructed sample value. Predicted quantized residual value The residual is sent to the decoder using the same residual coding process as in transform skip mode residual coding. For lossless codecs, if slice_ts_residual_coding_disabled_flag is set to 1, the quantized residual value is sent to the decoder using regular transform residual coding. In terms of MPM modes for future intra mode codecs, for BDPCM-coded CUs, the horizontal prediction mode or the vertical prediction mode is stored if the BDPCM prediction direction is horizontal or vertical, respectively. For deblocking, if both blocks on either side of a block boundary are coded using BDPCM, then that particular block boundary is not deblocked. 2.2.4. Residual Codec for Transform Skip Mode VVC allows transform skip mode to be used for luma blocks of size up to MaxTsSize times 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. In transform skip mode, the residual of the TU is also encoded and decoded in units of non-overlapping sub-blocks of size 4x4. For better coding and decoding 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: – Forward scan order is applied to scan sub-blocks within a converted block and positions within a sub-block; – no signaling of the final (x, y) position; – When all previous flags are equal to 0, coded_sub_block_flag is coded 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; – The context model of the abs_level_gt1 flag also depends on the left sig_coeff_flag value and the top sig_co- eff_flag value; –par_level_flag uses only one context model; – Additional flags greater than 3, 5, 7, and 9 are signaled to indicate coefficient magnitudes, one context per flag; – For the binarization of the remainder values, the Rice parameter derivation uses a fixed order (order = 1); – The context model for the sign flag is determined based on the left and above neighboring values, and the sign flag is parsed 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), the encoding and decoding of the quantized residual magnitude is performed in three scanning passes (see Figure 16 ): – First scan pass: significance flag (sig_coeff_flag), sign flag (coeff_sign_flag), absolute magnitude greater than 1 flag (abs_level_gtx_flag[0]), and parity (par_level_flag) For a given scan position, if sig_coeff_flag is equal to 1, then coeff_sign_flag is encoded, followed by abs_level_gtx_flag[0] (which specifies whether the absolute magnitude is greater than 1). If abs_level_gtx_flag[0] is equal to 1, then par_level_flag is additionally encoded to specify the parity of the absolute magnitude. – Greater than x scan passes: For each scan position where the absolute magnitude is greater than 1, up to four abs_level_gtx_flag[i] (i=1...4) are encoded to indicate whether the absolute magnitude at the given position is greater than 3, 5, 7 or 9, respectively. – Remainder scan pass: The absolute magnitude remainder abs_remainder is encoded and decoded in bypass mode. The absolute magnitude remainder is binarized using a fixed Rice parameter value of 1. The bins in scan pass #1 and scan pass #2 (the first scan pass and greater than x scan passes) are context-coded until the maximum number of context-coded bins in the TU has been exhausted. The maximum number of context-coded bins in the residual block is limited to 1.75*block_width*block_height, or equivalently, an average of 1.75 context-coded bins per sample position. The bins in the last scan pass (the remainder scan pass) are bypass-coded. The variable RemCcbs is first set to the maximum number of context-coded bins for the block and is decremented by 1 each time a context-coded bin is coded. When RemCcbs is greater than or equal to 4, the syntax elements in the first codec pass are coded using context-coded bins, 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 in the remainder scan pass (pass #3). After the first pass of encoding and decoding is completed, if RemCcbs is greater than or equal to 4, the syntax elements in the second encoding and decoding pass are encoded using the bins of context encoding, including abs_level_gt3_flag, abs_level_gt5_flag, abs_level_gt7_flag, and abs_level_gt9_flag. If RemCcbs becomes less than 4 during the second pass of encoding and decoding, the remaining coefficients that have not been encoded in the second pass are encoded in the remainder scan pass (pass #3). Figure 16 The transform skip residual coding process is shown. The stars mark the positions where the context coded bits are exhausted, at which point all remaining bits are coded using the bypass codec. In addition, for blocks that are not coded in BDPCM mode, a magnitude mapping mechanism is applied to transform skip residual coding until the maximum number of bins for context coding has been reached. Magnitude mapping uses the top and left neighboring coefficient magnitudes to predict the current coefficient magnitude in order to reduce signaling overhead. For a given residual position, denote absCoeff as the absolute coefficient magnitude before mapping, and absCoeffMod as the coefficient magnitude after mapping. Let X0 denote the absolute coefficient magnitude of the left neighboring position, and let X1 denote the absolute coefficient magnitude of the upper neighboring position. Magnitude mapping is performed as follows: pred=max(X0,X1); if(absCoeff == pred) absCoeffMod = 1; else absCoeffMod=(absCoeff <pred)?absCoeff+1:absCoeff; The absCoeffMod value is then encoded as described above.After all context encoded bins have been exhausted, magnitude mapping is disabled for all remaining scan positions in the current block. 2.2.5. Palette Mode In VVC, palette mode is used for screen 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 64x64, a flag is sent 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 with less than or equal to 16 samples. The codec unit (CU) for palette encoding is treated as a prediction mode different from intra prediction, inter prediction and intra block copy (IBC) mode. If palette mode is used, the sample values ​​in the CU are represented by a set of representative color values. This set is called a palette. For positions with sample values ​​close to the palette colors, the palette index is transmitted through the signal. It is also possible to specify samples outside the palette by signaling an escape symbol. For samples encoded and decoded using the escape symbol within the CU, their component values ​​are (possibly) directly transmitted through the signal using quantized component values. This is in Figure 17 The quantized escaped symbols are binarized using a fifth-order exponential Golomb binarization process (EG5). For palette encoding and decoding, palette prediction values ​​are maintained. For the non-wavefront case, the palette prediction values ​​are initialized to 0 at the beginning of each slice. For the WPP case, the palette prediction values ​​at the beginning of each CTU row are initialized to the prediction values ​​derived from the first CTU in the previous CTU row, so that the initialization scheme between the palette prediction values ​​and CABAC synchronization is unified. For each entry in the palette prediction value, the reuse flag is transmitted via a signal to indicate whether it is part of the current palette in the CU. The reuse flag is sent using run-length coding of zeros. Thereafter, the number of new palette entries and the component values ​​for the new palette entries are transmitted via a signal. After encoding a CU for palette encoding and decoding, the palette prediction value will be updated using the current palette, and entries from the previous palette prediction value that are not reused in the current palette will be added at the end of the new palette prediction value until the maximum allowed size is reached. The escape flag is transmitted for each CU through a signal 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 entry and the last index is assigned to the escape symbol. In a manner similar to the coefficient groups (CGs) used in transform coefficient coding, a CU coded using palette mode is divided into multiple row-based coefficient groups, each consisting of m samples (i.e., m=16), where for each CG, index runs, palette index values, and quantized colors for escape mode are sequentially coded / parsed. Figure 18 As shown in , as in HEVC, horizontal or vertical traversal scanning can be applied to scan the samples. The coding order for palette run-length coding in each segment is as follows: For each sample position, one context-coded binary bit run_copy_flag=0 is transmitted by signal to indicate whether the pixel has the same mode as the previous sample position, that is, whether the previously scanned sample and the current sample are both of run type COPY_ABOVE, or whether the previously scanned sample and the current sample are both of run type INDEX and have the same index value. Otherwise, run_copy_flag=1 is transmitted by signal. If the current sample has a different mode from the previous sample, one context-coded binary bit copy_above_palette_indices_flag is transmitted by signal 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 INDEX mode is used by default. In the same way, if the previously parsed run type is COPY_ABOVE, the decoder does not need to parse the run type. After palette run encoding and decoding of samples in one codec pass, the index values ​​(for INDEX mode) and quantized escape colors are grouped and encoded in another codec pass using CABAC bypass codec. This separation of context-encoded bits and bypass-encoded bits can improve the throughput within each row of CG. For slices with dual luma / chroma trees, the palette is applied separately to luma (Y component) and chroma (Cb component and Cr component), 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 jointly on the Y, Cb, Cr components, i.e., each entry in the palette contains a Y value, a Cb value, a Cr value, unless the CU is coded using a local dual tree, in which case the coding of luma and chroma is handled separately. In this case, if the corresponding luma block or chroma block is coded 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.2.5.1.). For slices utilizing 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 utilizing dual-tree codec, the maximum predictor and palette table sizes are halved, i.e., for each of the luma palette and chroma palettes, the maximum predictor size is 31 and the maximum table size is 15. For deblocking, palette-coded blocks on either side of a block boundary are not deblocked. 2.2.5.1. Palette Mode for Non-4:4:4 Content The palette modes in VVC are supported for all chroma formats in a similar way to the palette modes in HEVC SCC. For non-4:4:4 content, the following customizations are applied: 1. When signaling an escape value for a given sample position, if that sample position has only a luma component but no chroma components due to chroma downsampling, only the luma escape value is signaled. This is the same as in HEVC SCC. 2. For local dual-tree blocks, the palette mode is applied to the block in the same way as the palette mode applied to single-tree blocks, with two exceptions: a. The process of updating the palette prediction value is slightly modified as follows. Since the local dual-tree block only contains luminance (or chrominance) components, so the prediction value update process uses the signaled values ​​of the luminance (or chrominance) components and fills in the "missing" chrominance (or luminance) components by setting them to default values ​​(1<<(component bit depth-1)). b. The maximum palette prediction value size is kept at 63 (because slices are coded using a single tree), but the maximum palette table size for luma / chroma blocks is kept at 15 (because blocks are coded 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.2.5.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 this 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-dependent and is retrieved from a lookup table containing 57 elements covering the entire QP range. After all samples of the current CU have been processed, the initial palette entries are sorted according to the number of samples clustered with each palette entry, and any entries after the 31st entry are discarded. 2. In the second step, the initial palette table colors are adjusted by considering two options: using the centroid of each cluster from step 1 or using one of the palette colors in the palette prediction value. 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 prediction value, 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 predictions. Therefore, the table is reordered again so that all new entries (i.e., centroids) is placed at the beginning of the table, followed by entries for predicted values ​​from the palette. 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 entries and the RD cost of the index representing the escaped symbol, and selects the index with the minimum RD cost using the following equation: RD cost = distortion × (isChroma?0.8:1) + λ × bits of bypass coding (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 is removed. After the index map of the current CU is determined, a grid RD optimization is applied to find the optimal run_copy_flag value and run type value for each sample position by comparing the RD costs of three options: the same as the previously scanned position, run type COPY_ABOVE, or run type INDEX. When calculating the SAD value, the sample value is scaled down to 8 bits unless the CU is encoded 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 bit rate is used in the above rate-distortion optimization step (because lossless codecs do not cause distortion). 2.2.6. Adaptive Color Transformation In the HEVC SCC extension, Adaptive Color Transform (ACT) is applied to reduce 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. 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 19The decoding flow chart for applying ACT is shown. The 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 only enabled when there is at least one non-zero coefficient in the CU. For intra CUs, ACT is only enabled when the chroma components select the same intra prediction mode (i.e., DM mode) as the luma component. 2.2.6.1.ACT 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, the flag indicating whether the lossy or lossless codec is applied is not signaled in the bitstream. 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, to compensate for the dynamic range variation of the residual signal before and after color conversion, QP adjustments of (-5, 1, 3) are applied to the transformed residuals of the Y, Cg, and Co components, respectively. The adjusted quantization parameters only affect the quantization and inverse quantization of the residual in the CU. For other codec processes (such as deblocking), the original QP is still applied. In addition, because the forward and inverse color transforms require access to the residuals of all three components, ACT mode is always disabled for separate-tree partition and ISP mode, where the prediction block sizes of different color components are different. When ACT is applied, transform skip (TS) and block differential pulse code modulation (BDPCM) extended to the coded chroma residual are also enabled. 2.2.6.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 enabling / disabling RD checking for ACT depends on the original color space of the input video. For RGB video, the RD cost of ACT mode is checked first; for YCbCr video, the RD cost of non-ACT mode is checked first. The RD cost of the second color space is only checked if there is at least one non-zero coefficient in the first color space. – When a CU is obtained through different split paths, the same ACT enable / disable decision is reused. Specifically, when the CU is first encoded and decoded, the selected color space used for residual encoding of a CU will be stored. Then, when the same CU is obtained through 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 determine 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 of the parent CU, the second color space is not checked for the current CU. To reduce the number of codec modes tested, the selected codec mode is shared between the two color spaces. Specifically, for intra mode, pre-selected intra mode candidates based on SATD-based intra mode selection are shared between the two color spaces. For inter mode and IBC mode, block vector search or motion estimation is performed only once. Block vectors and motion vectors are shared between the two color spaces. 2.2.7. Intra-frame Template Matching (Intra-frame TMP) Intra Template Matching (Intra TMP) is a special intra prediction mode that copies the best prediction block from the reconstructed portion of the current frame, whose L-shaped template matches the current template. For a predefined search range, the encoder searches for the template most similar to the current template in the reconstructed portion of the current frame and uses the corresponding block as the prediction block. The encoder then signals the use of this mode, and the same prediction operation is performed on the decoder side. The prediction signal is obtained by combining the L-shaped causal neighbor of the current block with Figure 20 The search area is generated by matching another block in a predefined search area. The search area consists of the following components: 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 template and uses its corresponding block as the prediction block. The dimensions of all regions (SearchRange_w, SearchRange_h) are set proportionally to the block dimensions (BlkW, BlkH) so that each pixel has a fixed number of SAD comparisons. That is: SearchRange_w=a*BlkW SearchRange_h=a*BlkH Where "a" is a constant that controls the gain / complexity tradeoff. In practice, "a" is equal to 5. The intra template matching tool is enabled for CUs with size less than or equal to 64 in width and height. The 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.8. Using Block Vectors Derived from Intra-TMP for IBC The block vector (BV) derived from intra template matching prediction (intra TMP) is used for intra block copy (IBC). The stored intra TMP BV and IBC BV of the neighboring blocks are used as spatial BV candidates in the IBC candidate list construction. 2.2.9. Direct Block Vector (DBV) Mode for Chroma Prediction For chroma components, when the chroma dual tree is activated in an intra slice, if one of the luma blocks (five positions) is coded in MODE_IBC, its block vector bvL is used and scaled to derive the chroma block vector bvC. The scaling factor depends on the chroma format sampling structure. Figure 21 Five positions in the reconstructed luminance samples are shown. Then, by using the position of the current chroma block (xCb, yCb) and its bvC, the corresponding offset position (xCb+bvC[0], yCb+bvC[1]) is determined, and block copy prediction is performed. Figure 22 The prediction process for the DBV model is shown. A CU level flag is signaled to indicate whether the proposed DBV mode is applied, as shown in Table 2-2. Table 2-2 Binarization process for intra_chroma_pred_mode in the proposed method 2.3 Transform and Coefficient Encoding and Decoding 2.3.1. Large Block Size Transformation with High-Frequency Zeroing In VVC, large block size transforms of up to 64x64 are enabled, which are mainly used for higher resolution video, such as 1080p and 4K sequences. For transform blocks with a size (width or height, or both width and height) equal to 64, the high-frequency transform coefficients are cleared so that only the lower-frequency coefficients are retained. For example, for an M×N transform block, where M is the block width and N is the block height, when M is equal to 64, only the left 32 columns of transform coefficients are retained. Similarly, when N is equal to 64, only the top 32 rows of transform coefficients are retained. When transform skip mode is used for large blocks, the entire block is used without clearing any values. In addition, transform displacement is removed in transform skip mode. VTM also supports configurable maximum transform size in SPS, giving the encoder the flexibility to select up to 32-length or 64-length transform size according to the needs of a specific implementation. 2.3.2. Multiple Transformation Selection (MTS) for Kernel Transformations In addition to the DCT-II already adopted in HEVC, the Multiple Transform Selection (MTS) scheme is also used for residual coding of both inter-frame and intra-frame codec blocks. It uses multiple selected transforms from DCT8 / DST7. The newly introduced transform matrices are DCT-VII and DCT-VIII. Table 2-3 shows the selected DST / DCT basis functions. Table 2-3 Transform basis functions of DCT-II / VIII and DSTVII for N-point input To maintain orthogonality of the transform matrix, the transform matrix is ​​quantized more accurately than the transform matrix in HEVC. To keep the intermediate values ​​of the transform coefficients within 16 bits, all coefficients are 10 bits after horizontal and vertical transforms. To control the MTS scheme, separate enable flags are specified at the SPS level for intra and inter frames. When MTS is enabled at the SPS, a CU-level flag is signaled to indicate whether MTS is applied. Here, MTS applies only to luma. MTS signaling is skipped when one of the following conditions applies: - The position of the last significant coefficient of the luma TB is less than 1 (ie only DC). —The last significant coefficient of the luminance TB is located within the MTS zeroing region. If the MTS CU flag is equal to 0, DCT2 is applied in both directions. However, if the MTS CU flag is equal to 1, two other flags are additionally transmitted via a signal to indicate the transform type for the horizontal and vertical directions, respectively. The transform and signaling mapping table is shown in Table 2-4. By eliminating the intra mode and block shape dependency, a unified transform selection for ISP and implicit MTS is used. If the current block is in ISP mode or if the current block is an intra block and both intra and inter explicit MTS are enabled, only DST7 is used for both horizontal and vertical transform kernels. In terms of transform matrix accuracy, an 8-bit main transform kernel is used. Therefore, all transform kernels used in HEVC are kept the same, including 4-point DCT-2 and DST-7, 8-point, 16-point and 32-point DCT-2. In addition, other transform kernels (including 64-point DCT-2, 4-point DCT-8, 8-point, 16-point, 32-point DST-7 and DCT-8) all use an 8-bit main transform kernel. Table 2-4 Conversion and signaling mapping table To reduce the complexity of large-size DST-7 and DCT-8, high-frequency transform coefficients are cleared to zero for DST-7 and DCT-8 blocks with size (width or height, or both) equal to 32. Only coefficients in the 16×16 low-frequency region are retained. As in HEVC, the residual of a block can be coded using transform skip mode. To avoid syntax coding redundancy, the transform skip flag is not signaled when the CU-level MTS_CU_flag is not equal to 0. Note that when LFNST or MIP is activated for the current CU, the implicit MTS transform is set to DCT2. In addition, when MTS is enabled for an inter-coded block, implicit MTS can still be enabled. 2.3.3. Low-Frequency Non-Separable Transform (LFNST) In VVC, such as Figure 23 As shown, LFNST is applied between the forward main transform and quantization (at the encoder) and between dequantization and the inverse main transform (at the decoder). In LFNST, either a 4x4 non-separable transform or an 8x8 non-separable transform is applied depending on the block size. For example, 4x4 LFNST is applied to small blocks (i.e., min(width, height) < 8), and 8x8 LFNST is applied to larger blocks (i.e., min(width, height) > 4). The application of the non-separable transform used in LFNST is described below using the input as an example. To apply 4x4 LFNST, the 4x4 input block X is first represented as a vector The inseparable transform is calculated as where indicates the transform coefficient vector, and T is a 16x16 transform matrix. The 16x1 coefficient vector is then reorganized into 4x4 blocks using a scan order for the block (horizontal, vertical, or diagonal). Coefficients with smaller indices will be placed in the 4x4 coefficient block along with smaller scan indices. 2.3.3.1. Reduced inseparable transform The LFNST (Low Frequency Non-Separable Transform) applies the non-separable transform based on the direct matrix multiplication method such that it is implemented in a single pass without multiple iterations. However, the dimension of the non-separable transform matrix needs to be reduced to minimize the computational complexity and the memory space to store the transform coefficients. Therefore, the Reduced Non-Separable Transform (or RST) method is used in the LFNST. The main idea of the reduced non-separable transform is to map an N (for 8x8 NSST, N is usually equal to 64) -dimensional vector to an R -dimensional vector in a different space, where N / R (R < N) is the reduction factor. Thus, instead of an NxN matrix, the RST matrix becomes an R×N matrix as follows: The R rows of the transform are the R basis of the N-dimensional space. The inverse transform matrix of the RT is the transpose of its forward transform. For 8x8 LFNST, a reduction factor of 4 is applied, and the 64x64 direct matrix (which is the size of a conventional 8x8 non-separable transform matrix) is reduced to a 16x48 direct matrix. Therefore, a 48x16 inverse RST matrix is ​​used on the decoder side to generate the core (main) transform coefficients in the 8x8 upper left region. When a 16x48 matrix is ​​applied instead of a 16x64 with the same transform set configuration, each of them takes 48 input data from three 4x4 blocks in the upper left 8x8 block, excluding the lower right 4x4 block. With the reduced dimensionality, the memory usage for storing all LFNST matrices is reduced from 10KB to 8KB, with a reasonable performance degradation. To reduce complexity, LFNST is limited to being applicable only when all coefficients outside the first coefficient subgroup are insignificant. Therefore, when LFNST is applied, all pure main transform coefficients must be zero. This allows for LFNST index signaling to be adjusted at the last significant position, thus avoiding the extra coefficient scans in current LFNST designs, which only require checking significant coefficients at specific positions. The worst-case processing of LFNST (in terms of per-pixel multiplications) limits the non-separable transform to 8x16 and 8x48 transforms for 4x4 and 8x8 blocks, respectively. In these cases, when LFNST is applied, the last significant scan position must be less than 8, and less than 16 for other sizes. For blocks with 4xN and Nx4 (N>8) shapes, the proposed restrictions mean that LFNST is now applied only once, and only to the top-left 4x4 region. Since all pure main transform coefficients are zero when LFNST is applied, the number of operations required for the main transform is reduced in this case. From the encoder's perspective, coefficient quantization is significantly simplified when the LFNST transform is tested. Rate-distortion-optimized quantization only needs to be performed on the first 16 coefficients (in scan order); the remaining coefficients are forced to zero. 2.3.3.2. LFNST Transform Selection In LFNST, a total of 4 transform sets are used, each containing 2 inseparable transform matrices (kernels). As shown in Table 2-5, the mapping from intra prediction modes to transform sets is predefined. If one of the three CCLM modes (INTRA_LT_CCLM, INTRA_T_CCLM, or INTRA_L_CCLM) is used for the current block (81 <= predModeIntra <= 83), transform set 0 is selected for the current chroma block. For each transform set, the selected inseparable secondary transform candidate is further specified by an LFNST index that is explicitly signaled. This index is transmitted only once in the bitstream after the transform coefficients of each intra CU. Table 2-5 Conversion selection table 2.3.3.3.LFNST Index Signaling and Interaction with Other Tools Since LFNST is restricted to being applicable only when all coefficients outside the first coefficient subgroup are insignificant, the LFNST index encoding depends on the position of the last significant coefficient. In addition, the LFNST index is context-encoded, but does not depend on the intra prediction mode, and only the first bin is context-encoded. In addition, LFNST is applied to intra CUs in intra and inter slices, and to both luma and chroma. If dual-tree is enabled, the LFNST indexes for luma and chroma are signaled separately. For inter slices (dual-tree disabled), a single LFNST index is signaled and used for both luma and chroma. Considering that large CUs larger than 64x64 are implicitly partitioned (TU slicing) due to the existing maximum transform size limit (64x64), LFNST index searches can quadruple the data buffering for a given number of decoding pipeline stages. Therefore, the maximum size allowed for LFNST is limited to 64x64. Note that LFNST is only enabled with DCT2. LFNST index signaling is placed before MTS index signaling. The use of scaling matrices for perceptual quantization is not explicit. The scaling matrices specified for the master matrix can be used for LFNST coefficients. Therefore, the use of scaling matrices for LFNST coefficients is not allowed. For single-tree partitioning mode, chroma LFNST is not applied. 2.3.4. Sub-block Transform (SBT) In VTM, sub-block transform is introduced for inter-predicted CUs. In this transform mode, only a sub-part of the residual block is encoded and decoded for the CU. When an inter-predicted CU has cu_cbf equal to 1, cu_sbt_flag can be signaled to indicate whether the entire residual block or a sub-part of the residual block is encoded and decoded. For the former case, the inter MTS information is further parsed to determine the transform type of the CU. In the latter case, part of the residual block is encoded and decoded using the inferred adaptive transform, while the other part of the residual block is cleared to zero. When SBT is used for inter-coded CUs, the SBT type and SBT location information are signaled in the bitstream. Figure 24As shown, there are two SBT types and two SBT positions. For SBT-V (or SBT-H), the TU width (or height) can be equal to half of the CU width (or height) or 1 / 4 of the CU width (or height), resulting in 2:2 partitioning or 1:3 / 3:1 partitioning. The 2:2 partitioning is similar to the binary tree (BT) partitioning, while the 1:3 / 3:1 partitioning is similar to the asymmetric binary tree (ABT) partitioning. In the ABT partitioning, only small areas contain non-zero residuals. If one dimension of the CU is 8 (in units of luminance samples), 1:3 / 3:1 partitioning along this dimension is not allowed. The CU has a maximum of 8 SBT modes. In SBT-V and SBT-H, position-dependent transform kernel selection is applied to the luma transform block (chroma TBs always use DCT-2). Different kernel transforms are associated with the two positions, SBT-H and SBT-V. More specifically, the horizontal and vertical transforms for each SBT position are Figure 24 For example, the horizontal and vertical transforms for SBT-V position 0 are DCT-8 and DCT-7, respectively. When one side of the residual TU is larger than 32, the transforms for both dimensions are set to DCT-2. Therefore, the sub-block transform jointly specifies the horizontal and vertical kernel transform types for the TU slice, cbf, and residual block. SBT is not applied to CUs coded in the joint intra and inter modes. 2.3.5. Maximum Transform Size and Clearing of Transform Coefficients The CTU size and the maximum transform size (i.e., all MTS transform kernels) are both extended to 256, where the largest intra-coded block can have a size of 128x128. For UHD sequences, the maximum CTU size is set to 256, otherwise it is set to 128. During the main transform process, there is no normalized zeroing operation applied to the transform coefficients. However, if LFNST is applied, the main transform coefficients outside the LFNST region are normalized to zero. 2.3.6. Enhanced MTS for intra-frame coding and decoding In the current VVC design, for MTS, only DST7 and DCT8 transform kernels are used, which are used for intra and inter coding. Additional main transforms including DCT5, DST4, DST1 and identity transform (IDT) are adopted. At the same time, the MTS set is configured based on TU size and intra mode information. 16 different TU sizes are considered, and for each TU size, 5 different categories are considered based on intra mode information. For each category, 1, 4 or 6 different transform pairs are considered. The number of intra MTS candidates is adaptively selected (between 1, 4 and 6 MTS candidates) based on the sum of the absolute values ​​of the transform coefficients. The sum is compared with two fixed thresholds to determine the total number of allowed MTS candidates: 1 candidate: sum <= th0 4 candidates: th0 < total <= th1 6 candidates: total > th1. Note that although a total of 80 different classes are considered, some of these different classes often share exactly the same set of transforms. Hence there are 58 (less than 80) unique entries in the resulting LUT. For angle modes, the joint symmetry of TU shape and intra prediction is taken into account. Therefore, mode i (i>34) with TU shape AxB will be mapped to the same category corresponding to mode j=(68-i) with TU shape BxA. However, for each transform pair, the order of horizontal and vertical transform kernels is swapped. For example, a 16x4 block with mode 18 (horizontal prediction) and a 4x16 block with mode 50 (vertical prediction) are mapped to the same category. However, the vertical and horizontal transform kernels are swapped. For wide-angle mode, the closest conventional angle mode is used for transform set determination. For example, mode 2 is used for all modes between -2 and -14. Similarly, mode 66 is used for modes 67 to 80. 2.3.7. Secondary Transformation: Extension of LFNST with Large Kernel The LFNST design in VVC is extended as follows: The number of LFNST sets (S) and candidates (C) is extended to S=35 and C=3, and the LFNST set (lfnstTrSetIdx) for a given intra mode (predModeIntra) is derived according to the following formula: oFor predModeIntra<2, lfnstTrSetIdx is equal to 2 o For predModeIntra in [0,34], lfnstTrSetIdx = predModeIntra o For predModeIntra in [35,66], lfnstTrSetIdx = 68 - predModeIntra. Three different kernels LFNST4, LFNST8, and LFNST16 are defined to indicate that they are applied to 4xN / Nx4 respectively. (N≥4), 8xN / Nx8 (N≥8), and MxN (M, N≥16) LFNST kernel sets. The kernel dimension is given by the following formula: (LFSNT4, LFNST8*, LFNST16*) = (16x16, 32x64, 32x96) Forward LFNST is applied to the upper left low-frequency region called the Region-Of-Interest (ROI). When LFNST is applied, the main transform coefficients present in the region other than the ROI are cleared, which does not change the VVC standard. The ROI of LFNST16 is Figure 25 It is shown in . It consists of six 4x4 sub-blocks, which are consecutive in scan order. Since the number of input samples is 96, the transform matrix for forward LFNST16 can be Rx96. In this paper, R is chosen to be 32, and accordingly 32 coefficients (two 4x4 sub-blocks) are generated from forward LFNST16, which are placed according to the coefficient scan order. The ROI of LFNST8 is Figure 26 The forward LFNST8 matrix can be Rx64, and R is chosen to be 32. The generated coefficients are positioned in the same way as LFNST16. The mapping from intra prediction modes to these sets is shown in Tables 2-6. Table 2-6 Mapping of intra prediction modes to LFNST set indices Intra prediction mode -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 4 -3 -2 -1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 LFNST collection index 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Intra prediction mode 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 LFNST collection index 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 Intra prediction mode 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 LFNST collection index 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2.3.8. Symbol Prediction The basic idea of ​​the coefficient sign prediction methods (JVET-D0031 and JVET-J0021) is to compute the reconstruction residuals for negative and positive sign combinations for the applicable transform coefficients and select the hypothesis that minimizes the cost function. To derive the optimal symbol, the cost function is defined as Figure 27 The discontinuity measure across block boundaries is shown above. All hypotheses are measured, and the hypothesis with the smallest cost is chosen as the predicted value of the coefficient sign. The cost function is defined as the sum of the absolute second-order derivatives in the residual domain with respect to the upper rows and left columns as follows: Where R is the reconstructed neighbor, P is the prediction for the current block, and r is the residual hypothesis. The term (-R_(-1)+2R_0-P_1) can be computed only once per block and only the residual hypothesis is subtracted. The transform coefficients with the largest K qIdx values ​​in the upper left 4x4 region are selected. After compensating for the effects of multiple quantization values ​​in DQ, the qIdx value is the transform coefficient magnitude. Larger qIdx values ​​will produce larger dequantized transform coefficient magnitudes. qIdx is derived as follows: qIdx=(abs(level)<<1)-(state&1); where level is the transform coefficient magnitude parsed from the bitstream, and state is a variable maintained by the encoder and decoder in DQ. The symbol prediction area is expanded to a maximum of 32x32. The symbol of the upper left MxN block is predicted. The values ​​of M and N are calculated as follows: oM=min(w,maxW) oN=min(h,maxH) Where w and h are the width and height of the transform block. The maximum region for symbol prediction is not always set to 32x32. The encoder sets the maximum region (maxW, maxH) based on the configuration, sequence type, and QP, and signals this region in the SPS. The maximum number of prediction symbols remains unchanged. Symbol prediction is also applied to LFNST blocks. For LFNST blocks, a maximum of 4 coefficients in the upper left 4×4 region are allowed to be symbol predicted. 2.3.9. Non-separable primary transform (NSPT) for intra-frame coding and decoding DCT-II+LFNST is replaced by NSPT for block sizes 4x4, 4x8, 8x4, and 8x8, as shown in the figure below. Therefore, LFNST4 and LFNST8 will not be tested for these block sizes. However, they are still used for larger block sizes and are not removed. Therefore, NSPT can be considered an extension of the DCT-II+LFNST design. Figure 28 The process of the proposed design utilizing NSPT and LFNST is shown. The NSPT in this paper follows the design of LFNST, i.e. 3 candidates and 35 sets, selected based on intra-mode. The kernel size is as follows: NSPT4x4: 16x16 NSPT4x8 / NSPT8x4: 32x20 NSPT8x8: 64x32. Therefore, 12 and 32 coefficients are cleared to zero for NSPT4x8 / NSPT8x4 and NSPT8x8, respectively. 2.4. About intra-frame prediction and screen content coding in image and video coding The detailed solutions below should be considered as examples to explain the general concept. These solutions should not be interpreted in a narrow sense. In addition, these solutions can be combined in any way. The term “video unit” or “codec unit” may refer to a picture, a slice, a slice, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, or 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, or a TB. The term "block vector" may refer to the displacement / offset between a first block located at (x0, y0) and a second block located at (x1, y1). For example, it may be a motion vector of a block. For another example, it may be a block vector of a block. Figure 29 An example of a stitched chroma block is shown, which displays the current chroma block in a 4:2:0 color format. Table 2-7 SubWidthC and SubHeightC values ​​derived from chroma_format Chroma format SubWidthC SubHeightC monochrome 1 1 4:2:0 2 2 4:2:2 2 1 4:4:4 1 1 In the following discussion, the position of the "co-located luma block" can be derived from the position of the current chroma block according to the downsampling rate of the chroma format sampling structure (e.g., SubWidthC and SubHeightC as specified in Table 2-7). More specifically, assuming that the upper left sample of the chroma block is at position (xTbC, yTbC), the upper left sample position of the co-located luma block (xTbY, yTbY) is derived as follows: (xTbY, yTbY) = (xTbC*SubWidthC, yTbC*SubHeightC). Figure 30 As shown, for the 4:2:0 color format, the upper left sample of the current chroma block is located at (x=16, y=16) in the chroma picture, and then the upper left sample of its co-located luminance block is located at (x=32, y=32) in the luminance picture. Note that the terms mentioned below are not limited to the specific terms defined in existing standards, and any changes in codec tools are also applicable. Regarding intra / IBC chroma prediction (e.g., the first problem and related problems), the following methods are proposed: a. The block vector (BV) of a specific luma block can be used for chroma block encoding and decoding. a. In one example, whether and / or how to use the BV of a specific luma block for a chroma block may depend on whether the dual-tree structure is applied. b. For example, a specific luminance block can be intra-frame TMP coded. c. For example, a specific luma block may be IBC coded. d. For example, intra chroma mode can be derived based on luma blocks encoded using intra TMP. e. For example, the BV of the luma block of intra TMP encoding can be stored in a buffer, and this BV can be used for subsequent chroma encoding. f. For example, a scaled BV can be generated from a coded luma block with a BV and used for the chroma codec. i. In one example, the coded luma block may be intra-TMP coded. ii. For example, the scaling factor may be calculated based on the chroma downsampling ratio between luma and chroma. iii. For example, the scaling factor may depend on the color format such as 4:2:0 or 4:4:4. iv. For example, the scaled BV can be calculated based on the scaling factor and / or offset and / or displacement, for example, scaledBV=(a*lumaBV+b)>>s, where a represents the scaling factor, b represents the offset, and s represents the displacement factor. 1. For example, s can be a positive integer, 0, or a negative integer. g. In one example, a specific luma pattern may refer to a co-located luma block and / or its spatially (adjacent / non-adjacent) neighboring blocks, and / or a luma block having a different position than the co-located luma block. h. In one example, a specific luma block may be located in a reconstructed luma block in a region co-located with the current chroma CU. i. In one example, the size of a particular luma block may be MxN. 1. In one example, the size of a particular luminance block may be 4x4. 2. In one example, the size of a particular luminance block may be 8x8. ii. In one example, the specific luma block may be any MxN block. iii. In one example, the specific luminance block may be some predefined MxN blocks. iv. In one example, a specific luminance block may be located at a specific position in a region, Such as the center. b. In one example, the BV(s) derived from the luma block may be used for the chroma blocks. a. In one example, a message (eg, syntax parameter / variable / index / flag) may be transmitted via a signal to indicate which BV is applied. b. In one example, which BV is applied is derived at the decoder. c. In one example, multiple BVs may be derived from different luma block(s). i. In one example, the luma block may be located at a different position in the region co-located with the current chroma CU. c. It can be used for new signaled intra chroma modes (eg DBV mode). a. For example, if this newly signaled intra chroma mode is used, the chroma prediction block can be derived by directly copying the reference chroma block pointed to by a scaled BV that is downsampled from the BV of a coded luma block with BV. i. In one example, the coded luma block can be intra TMP coded. d. It can be used in existing intra chroma modes (eg, DM mode). a. For example, if such an existing intra chroma mode is used and a particular luma block has a BV, then (instead of using a default mode such as planar mode for chroma encoding), the chroma prediction block can be derived by directly copying the reference chroma block pointed to by the scaled BV, where the scaled BV is downsampled from the BV of the particular luma block. i. In one example, a specific luma block may be intra-TMP coded. ii. In one example, a specific luma block may be IBC coded. b. For example, if such an existing intra chroma mode is selected and a particular luma block is coded in IBC, then (instead of using a default mode such as DC mode for chroma coding), the chroma prediction block can be derived by directly copying the reference chroma block pointed to by the scaled BV, where The scaled BV is downsampled from the BV of the luma block in the IBC codec. e. It can be used in IBC colorimetric mode. a. For example, if such an IBC chroma mode is used and a particular luma block has a BV, the chroma prediction block can be derived by directly copying the reference chroma block pointed to by the scaled BV, where the scaled BV is downsampled from the BV of the particular luma block. i. In one example, a specific luma block may be intra-TMP coded. b. Alternatively, the BV of a specific luma block (eg, IBC coded, or intra TMP coded) may be used as a prediction value for the current chroma block codec. f. It can be used in intra TMP chroma mode. a. For example, if such an intra TMP chroma mode is used and a particular luma block has a BV, the chroma prediction block can be derived by directly copying the reference chroma block pointed to by the scaled BV, where the scaled BV is downsampled from the BV of the particular luma block. i. In one example, a particular luma block can be intra-TMP coded. g. Whether and how to check whether an intra-TMP coded luma block can be obtained during chroma coding of the current block. Depends on the availability of luma blocks from the IBC codec. a. For example, only when the luma block at a predefined position is not IBC coded, the BV of the intra-frame TMP coded luma block at this position can be used. b. For example, only when none of the luminance blocks in the first group are IBC coded, the intra The BV of the luma block of the TMP codec can be checked. i. For example, the position of the first group of luminance blocks can be the same as the position of the second group of luminance blocks (or different). ii. For example, the order in which the first set of luminance blocks are checked may be the same as (or different from) the order in which the second set of luminance blocks are checked. h. Whether and how to check IBC-coded luma during chroma codec of the current block may depend on the availability of intra-frame TMP-coded blocks. a. For example, only when the luma block at a predefined position is not intra-TMP coded, the BV of the IBC coded luma block at this position may be used. b. For example, only when none of the luma blocks in the first group are intra TMP coded, the BVs of the IBC coded luma blocks in the second group can be used. i. For example, the position of the first group of luminance blocks can be the same as the position of the second group of luminance blocks (or different). ii. For example, the order in which the first set of luminance blocks are checked may be the same as (or different from) the order in which the second set of luminance blocks are checked. i. For example, both the luma block of intra-frame TMP codec and the luma block of IBC codec can be checked based on predefined rules. j. For example, the first available / valid BV of an intra TMP (and / or IBC) coded luma block may be used. k. For example, more than one BV is selected based on predefined rules, and all BVs are placed in a table / list. a. For example, which BV is used for a chroma block can be derived implicitly based on codec information (eg, decoder-derived method). b. For example, which BV is used for a chroma block can be explicitly signaled through a syntax element (eg, an index). l. For example, available / valid BVs can be sorted by predefined rules (e.g., reordering based on template cost) are sorted. a. For example, the first order BV (eg, with the smallest cost) can be used directly. b. For example, which BV is used can be transmitted via a signal. m. It can be enabled in the codec of the content captured by the camera. n. It can be enabled in the codec for screen content. o. It can be enabled in single-tree codec. p. It can be enabled in dual-tree codec. 2.4.2. Regarding intra-frame luma codecs using adjacent intra-frame TMP / IBC information (e.g., the second and related issues), the following methods are proposed: a. The block vectors of the neighboring blocks of the intra TMP (and / or IBC, and / or intra) codec can be used for the current intra block codec. a. For example, the current intra block is the luminance component. b. For example, the current intra block is a chroma component. c. For example, when constructing the MPM list for the current block, if the neighbor is coded with intra TMP (or IBC), the current intra block codec may be applied based on the BV associated with the neighboring block. i. For example, the BV associated with the neighboring block can be directly used for the current intra block encoding. d. For example, an indicator (e.g., an index or flag) may be inserted into the MPM list that indicates whether a neighboring block (e.g., at a particular location) is coded in intra TMP (or IBC) mode, and if so, the current intra block codec may be applied based on the BV associated with the neighboring block. e. For example, a BV associated with an intra TMP (or IBC) block can be mapped to a regular intra mode (eg, with a specific angle), and then used for current intra-frame block coding. i. For example, the mapping process can be based on gradient, gradient histogram, DIMD, TIMD, etc. 2.4.3. Other improvements for screen content encoding and decoding: a. IBC can be allowed to be used as an assumption for the MHP model. b. Intra-frame TMP may be allowed to be used as an assumption for MHP mode. c. Block-level adaptive OBMC on / off can be used according to the decoder-derived method. a. For example, OBMC may be disabled / enabled (eg, not signaled) based on gradient calculations at prediction samples prior to OBMC. b. For example, based on the gradient histogram of the prediction samples before OBMC, OBMC can be disabled / enabled (eg, not signaled). c. For example, it can be used in Merge mode. d. For example, it can be used in AMVP mode. e. For example, it can be used in IBC mode. f. For example, it can be used in inter-frame mode. g. For example, it can be used in intra-frame TMP mode. 2.4.4. Other improvements for intra-frame prediction codec: a. Whether to use a specific intra prediction mode (eg, horizontal mode and / or vertical mode) can be derived based on gradients. a. For example, the gradient can be calculated from a template constructed from neighboring points. b. For example, DIMD-based methods can be used to calculate gradients. c. For example, if the histogram of gradients along the horizontal / vertical direction is dominant over other directions, the horizontal / vertical mode is used. i. For example, in this case, intra prediction may not be merged with other modes. ii. For example, in this case, there is no need to transmit by signal whether the horizontal mode or the vertical mode is used. iii. For example, a new intra mode may be signaled for this mode. 1. For example, syntax flags can be transmitted via signals. 2. For example, syntax parameters (eg, mode index) may be transmitted via signals. d. For example, it can be used for the luminance component. e. For example, it can be used for chroma components. 2.4.5. Whether and / or how to apply the above-disclosed method can be transmitted by a signal at the sequence level / picture group level / picture level / slice level / slice group level, such as in the sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / slice group header. 2.4.6. Whether and / or how the above disclosed methods may be applied may be signaled at a PB / TB / CB / PU / TU / CU / VPDU / CTU / CTU row / slice / slice / sub-picture / other type of region containing more than one sample or pixel. 2.4.7. Whether and / or how to apply the above disclosed methods may depend on codec information such as block size, color format, single / dual tree partitioning, color component, slice / picture type. 3. Question There are several problems with existing video coding and decoding technologies, which need to be further improved for higher coding and decoding gains. 1. DBV mode inherits block vectors from five predefined locations, which is suboptimal. 2. The validation check rules for block vectors in DBV mode can be improved. 3. The block vector derived from the luma block can be further refined. However, how the block vector is refined can be further improved. 4. In the case that all block vectors of the luminance block are invalid for the chrominance block, the DBV mode is changed to the planar mode. This can be further designed. 5. The DBV pattern is treated as a plane for LFNST, which is suboptimal. 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 manner. 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 slice, a codec tree block (CTB), a codec tree unit (CTU), a codec block (CB), a CU, a PU, a TU, a PB, or 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, or a TB. The term "block vector" may refer to the displacement / offset between a first block located at (x0, y0) and a second block located at (x1, y1). For example, it may be a motion vector of a block. For another example, it may be a block vector of a block. Note that the terms mentioned below are not limited to the specific terms defined in existing standards, and any changes in codec tools are also applicable. 4.1. Regarding which luma blocks will be used to derive the block vector for DBV mode (eg, the first question and related questions), the following approach is proposed. a. The block vector of the DBV mode for the chroma block can be derived based on the block vector of the luma block at a specific predefined position other than the center, upper left, upper right, lower left, and lower right. a. For example, the predefined position can be based on the following position of the current chroma block (in Figure 30 is represented as A, B, C, ... F, H) calculated by one or more brightness positions (in Figure 30 Indicated as A', B', C', ... F', H'). i. The center position between the upper left and upper right of the current block (for example, represented as “A”). ii. The center position between the upper left and lower left of the current block (for example, represented as “B”). iii. The center position between the upper right and lower right of the current block (for example, represented as “C”). iv. The center position between the lower left and lower right of the current block (for example, represented as “D”). v. The middle position of the upper left quarter of the current block (for example, represented as “E”). vi. The middle position of the upper right quarter of the current block (for example, represented as “F”). vii. The middle position of the lower left quarter of the current block (for example, represented as "G"). viii. The middle position of the lower right quarter of the current block (for example, represented as “H”). b. In one example, BV and IBC modes (such as RR-IBC mode) can be derived based on statistical information from the luma region corresponding to the current chroma block. i. For example, the average BV of the BVs in the luma region may be used for chroma. ii. For example, the BV shared by the maximum luma sample area can be used for chroma. c. For example, whether to check the predefined position may depend on the codec information of the video unit. i. For example, the codec information may be block dimensions (eg, width and / or height of the current block). ii. For example, the predefined position may be checked only if the width and / or height of the current (chroma) block is not smaller than (or larger than) a threshold value T (eg, such as T=4 or 8 or 16). d. For example, whether to check a predefined position may depend on whether none of the block vectors derived based on other group positions (e.g., center, top left, top right, bottom left, and bottom right positions) are valid. i. For example, if none of the luma blocks derived based on other group positions are coded with IBC (and / or intra TMP), then the predefined position may be checked. ii. For example, if none of the valid block vectors (e.g., although there is a block vector derived based on the luma position, it points to an invalid area that is not suitable for use in the current chroma block) is derived based on other group positions, then the predefined positions can be checked. e. For example, the block vector obtained based on the predefined position can be adjusted based on the displacement relationship between the current chroma block and the co-located luminance block / sub-block, and the reconstruction-reordering IBC (RR-IBC) flip type of the block vector. i. For example, if the luma block is RR-IBC coded, its block vector may first be adjusted by an offset before being inherited as the block vector for the chroma blocks. 1. For example, the offset can be determined based on the displacement relationship between the current chroma block and the co-located luma block / sub-block. 2. For example, the offset may be determined based on the flip type of the luma block of the RR-IBC codec. ii. For example, the flip type of the luma block in RR-IBC coding can be inherited to the chroma block. b. The block vector of the DBV mode for the chroma block can be derived based on the block vector of the luma sub-block with NxN granularity. a. For example, the block vector of each NxN (e.g., N=4 or 8) sub-block of a co-located luma block (which overlaps with the area of ​​the current chroma block depending on the downsampling rate) can be examined to derive the block vector of the DBV mode for the current chroma block. b. For example, each basic unit (such as a 4x4 block) in the luma region corresponding to the current chroma block may be checked sequentially. i. The sequence can be raster scan. 1. Raster scan can be from upper left to lower right, or vice versa. 2. Raster scanning can be from upper right to lower left, or vice versa. ii. The sequence may be a spiral scan from the center to the periphery. iii. The sequence may be a spiral scan from the periphery to the center. iv. The sequence can be a zigzag scan. c. For example, the block vector for DBV mode may be derived based on the first available block vector of the NxN sub-block of the co-located luma block. i. For example, whether it is available may depend on whether the NxN sub-block is in IBC and / or intra TMP Mode is encoded and decoded. d. For example, the block vector for DBV mode can be derived based on the first valid block vector of the NxN sub-block of the co-located luma block. i. For example, whether it is valid may depend on whether the block vector is within the valid search area of ​​the DBV mode. ii. For example, the valid search area may be defined based on the valid area for the IBC mode. iii. For example, the valid search area can be defined based on the valid area for intra TMP mode. e. For example, the block vector for DBV mode may be derived based on the available / valid block vectors of all NxN sub-blocks of the co-located luma block. i. For example, which one is ultimately used can be signaled in the bitstream. ii. For example, which one is finally used can be derived by a decoder-side method (e.g., based on template cost). f. Similarly, based on the block vectors of the chroma sub-blocks with MxM (eg, M=2 or 4 or 8) granularity, the block vectors of the DBV mode for the chroma block can be derived. c. The block vector of the DBV mode for the chroma block can be derived based on the list of block vector candidates. a. For example, block vector candidates can be derived based on predefined positions. b. For example, the block vector candidate can be based on a certain checking rule (e.g., traversing all the same-position luminance blocks NxN sub-blocks) are derived. c. For example, which one is used last can be signaled in the bitstream. d. For example, which one is used in the end can be derived by a decoder-side method (e.g., based on template costs). d. In one example, a chroma block may be divided into sub-blocks, and each sub-block may derive its individual mode (such as IBC or RR-IBC) and / or BV. a. In one example, the residuals of multiple sub-blocks may be transformed / quantized / entropy coded as a whole. b. In one example, the residual of each sub-block can be transformed / quantized / entropy coded separately. 4.2. Regarding the validation check of block vectors for DBV mode (eg, the second problem and related problems), the following method is proposed. a. Whether a block vector is valid for DBV mode may depend on whether there are valid reference samples in the legal search area. b. Whether a block vector is valid for DBV mode may depend on the size of the valid reference area in the legal search area. a. For example, a threshold may be defined to regulate the effective portion of the reference block within the legal search region. c. For example, Figure 31 As shown, when a portion of the reference block ref0 is within the legal search area, BV0 can be considered valid. a. Alternatively, BV0 can be considered invalid because 1 / 2 of the reference block ref0 exceeds the legal search area. d. For example, Figure 31 As shown, when the entire area of ​​the reference block ref1 is within the legal search area, BV1 can be considered valid. e. For example, Figure 31 As shown, BV2 can be considered valid when the entire area of ​​the reference block ref2 is within the legal search area. f. For example, an invalid area of ​​a reference block (eg, reference samples outside a legal search area) may be filled with samples in a valid area of ​​the reference block. a. For example, the filling process can be based on repeated filling from a predefined order (e.g., from top to bottom, from bottom to top, from left to right, from right to left, etc.). 4.3. Regarding block vector refinement of chroma blocks for DBV mode coding (eg, the third problem and related problems), the following method is proposed. a. The explicit refinement process can be applied to the block vectors of chroma blocks coded in DBV mode. a. For example, a block vector offset can be applied on top of a block vector derived from the luma block. b. For example, suitable offset candidates may be predefined. i. For example, a list of appropriate offsets may be defined in a table. ii. For example, the appropriate offset may be indicated by an offset direction associated with an offset distance. c. For example, an indication of the block vector offset may be indicated in the bitstream. i. For example, it can be signaled as an offset index. ii. For example, it can be transmitted via a signal with a direction index and a distance index. b. The implicit refinement process can be applied to the block vectors of chroma blocks coded in DBV mode. a. For example, a search region may be defined such as having a displacement of (+ / -M, + / -M) samples in the horizontal and vertical directions, respectively. i. For example, M=2. b. For example, template matching based refinement can be applied to block vector refinement. c. For example, the final refined block vector can be determined based on the template cost. i. For example, the template can be constructed by the top and / or left neighboring samples adjacent to the current chroma block and the reference block. ii. For example, the template shape of the reference template may be adjusted rightward and / or downward according to a reconstruction-reordering IBC (RR-IBC) flipping type. 4.4. Regarding the fallback mode for DBV mode, in the case where all block vectors of the available luma blocks for the chroma blocks are invalid (eg, the fourth problem and related problems), the following method is proposed. a. In case all block vectors of luma blocks are invalid for chroma blocks, a specific LM (eg LM-TL or LM-T or LM-L) mode may be used instead of DBV mode. a. For example, in this case, the chroma fusion mode can be further applied. b. In case all block vectors of luma blocks are invalid for chroma blocks, a specific MMLM (eg, MMLM-TL or MMLM-T or MMLM-L) mode may be used instead of DBV mode. a. For example, in this case, the chroma fusion mode can be further applied. c. In the case where all block vectors of the available luma blocks are invalid for the chroma blocks, a specific CCCM (eg, CCCM-TL or CCCM-T or CCCM-L) mode may be used instead of the DBV mode. a. For example, in this case, the chroma fusion mode can be further applied. d. In case all block vectors of luma blocks are invalid for chroma blocks, a special GLM mode may be used instead of DBV mode. a. For example, in this case, the chroma fusion mode can be further applied. 4.5. Fusion of IBC in Chroma Blocks a. In one example, the IBC prediction samples and the prediction samples from the second prediction mode for the chroma block can be fused. a. In one example, the second prediction mode may be an inter-component mode, such as CCLM or CCCM. b. In one example, the second prediction mode may be an angular prediction mode. c. In one example, the IBC prediction samples and the prediction samples from the second prediction may be weighted summed to generate a prediction for further processing. In one example, the IBC prediction samples and the prediction samples from the second prediction may be combined in a manner defined by the SGPM. 4.6. About BVP for Chroma Blocks a. The BV of a chroma block can be predicted by the BV of neighboring chroma blocks. b. In one example, BV predictions or BV candidates derived from neighboring chroma blocks can be used together with the BV derived from the luma component. a. For example, if the BV derived from the luma component is not available, a BV prediction or BV candidate derived from neighboring chroma blocks may be used. b. For example, if a BV prediction or BV candidate derived from neighboring chroma blocks is not available, the BV derived from the luma component may be used. c. BV predictions or BV candidates derived from neighboring chroma blocks and the BV derived from the luma component may be placed into a single candidate list to be selected from. 4.7. Regarding the intra mode used to derive the transform kernel for chroma blocks for DBV mode coding (eg, the fifth problem and related problems), the following method is proposed. a. The intra mode derived by the decoder can be used to derive the transform kernel for the chroma block for DBV mode encoding and decoding. a. For example, the intra mode derived by the decoder can be based on the neighboring samples of the current chroma block. b. For example, the intra mode derived by the decoder may be based on an intra mode based on a coded chroma block obtained according to a block vector of the current chroma block. c. For example, the intra mode derived by the decoder can be based on neighboring samples of the same-located luminance block. d. For example, the intra mode derived by the decoder can be based on the predicted / reconstructed samples of the co-located luminance block. e. For example, the intra mode derived by the decoder may be based on the intra mode of a luma block within a co-located luma block. f. For example, the intra mode derived by the decoder can be based on DIMD. g. For example, the intra mode derived by the decoder can be based on TIMD. h. For example, the intra mode derived by the decoder can be based on gradient histograms. b. A specific LM (eg, LM-TL or LM-T or LM-L) mode may be used to derive the transform kernel for chroma blocks for DBV mode coding. c. A specific MMLM (eg, MMLM-TL or MMLM-T or MMLM-L) mode may be used to derive the transform kernel for chroma blocks for DBV mode coding. d. A specific CCCM (eg, CCCM-TL or CCCM-T or CCCM-L) mode may be used to derive the transform kernel for chroma blocks for DBV mode coding. e. Specific GLM modes can be used to derive transform kernels for chroma blocks for DBV mode coding. f. The transformation kernel can be a specific MTS kernel. g. The transformation kernel can be a specific LFNST kernel. h. The transformation kernel can be a specific NSPT kernel. i. The transformation kernel can be a specific separable transformation kernel. j. The transformation kernel can be a specific inseparable transformation kernel. k. The transformation kernel can be a specific main transformation kernel. 1. The transformation kernel can be a specific quadratic transformation kernel. General aspects 4.8. The syntax elements disclosed above can be binarized as flags, fixed-length codes, EG(x) codes, unary codes, truncated unary codes, truncated binary codes, etc. It can be signed or unsigned. 4.9. The syntax elements disclosed above may be encoded or decoded using at least one context model, or may be bypassed. 4.10. The syntax elements disclosed above may be signaled in a conditional manner. 4.11. SE is transmitted via a signal only when the corresponding function is applicable. 4.12. The syntax elements disclosed above can be transmitted by signals at the block level / sequence level / picture group level / picture level / slice level / slice group level, such as in the codec structure of CTU / CU / TU / PU / CTB / CB / TB / PB or sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / slice group header. 4.13. Whether and / or how the above disclosed methods may be applied may be signaled at the block level / sequence level / group of picture level / picture level / slice level / slice group level, such as in the codec structure of CTU / CU / TU / PU / CTB / CB / TB / PB or sequence header / picture header / SPS / VPS / DPS / DCI / PPS / APS / slice header / slice group header. 4.14. Whether and / or how to apply the above disclosed methods may depend on codec information such as block size, color format, single / dual tree partitioning, color components, slice / picture type. 4.15. The proposed method disclosed in this paper can be used in other codecs that require chroma fusion.

[0089] Figure 32 FIG32 is a flow chart of a method 3200 for video processing according to an embodiment of the present disclosure. The method 3200 is implemented during conversion between a target video block of a video and a bitstream of the video.

[0090] At block 3210, for conversion between a video unit of a video and a bitstream of the video unit, a block vector for a direct block vector (DBV) mode for a chroma block of the video unit is derived based on one of the following: a block vector for a luma block at a predefined position, a block vector for a luma sub-block at NxN granularity, or a list of block vector candidates, where N is an integer.

[0091] At block 3220, conversion is performed based on the block vector of the DBV mode for the chroma block. In some embodiments, the conversion may include encoding the video unit from the bitstream. Alternatively or additionally, the conversion may include decoding the video unit from the bitstream. In this way, block-level adaptive OBMC that considers block characteristics based on decoded information can result in higher codec gain and improved codec efficiency.

[0092] In some embodiments, the block vector of each NxN luma sub-block of a co-located luma block that overlaps with an area of ​​a chroma block according to the downsampling rate is examined to derive the block vector of the DBV mode for the chroma block, where N is equal to 4 or 8.

[0093] In some embodiments, a block vector for DBV mode is derived based on a first available block vector for an NxN luma sub-block of a co-located luma block. In some embodiments, whether a block vector for an NxN luma sub-block of a co-located luma block is available may depend on whether the NxN sub-block is encoded or decoded using at least one of: intra block copy (IBC) mode or intra template matching prediction (intra TMP) mode. The block vector for DBV mode may be derived based on a first valid block vector for an NxN luma sub-block of a co-located luma block.

[0094] In some embodiments, whether a block vector of an NxN luma sub-block of a co-located luma block is valid depends on whether the block vector is within a valid search area for DBV mode. In some embodiments, the valid search area can be defined based on a valid area for IBC mode. Alternatively, the valid search area can be defined based on a valid area for intra TMP mode.

[0095] In some embodiments, each basic unit in the luminance area corresponding to the chrominance block is checked in sequence. The sequence can be a raster scan from the upper left to the lower right, or a raster scan from the upper right to the lower left, or a raster scan from the lower right to the upper left, or a raster scan from the lower left to the upper right. Alternatively, the sequence can be a spiral scan, which is a spiral scan from the center to the periphery or from the periphery to the center. In some embodiments, the sequence is a zigzag scan.

[0096] In some embodiments, the block vector of the DBV mode is derived based on the available block vectors or valid block vectors of all NxN luma sub-blocks of the co-located luma block. For example, which block of the NxN luma sub-block is used to derive the block vector of the DBV mode is indicated in the bitstream. As another example, which block of all NxN luma sub-blocks is used to derive the block vector of the DBV mode is derived by a decoder-side method (e.g., based on template cost). For example, the co-located luma block can be divided into multiple NxN luma sub-blocks. The chroma BV of the DBV mode can be derived based on one or more luma BVs of the multiple NxN luma sub-blocks. As an example, a valid BV can be selected from one or more luma BVs of the multiple NxN luma sub-blocks and used to derive the chroma BV of the DBV mode. Alternatively, all luma BVs in the multiple NxN luma sub-blocks can be used to derive the chroma BV of the DBV mode.

[0097] In some embodiments, method 3200 may further include deriving a block vector for a DBV mode for a chroma block based on a block vector for a chroma sub-block of MxM granularity. In this case, M may be an integer. For example, M may be 2, 4, or 8.

[0098] In some embodiments, the block vector obtained based on the predefined position is adjusted based on at least one of: a displacement relationship between the co-located chroma block and the luminance block or luminance sub-block, or a reconstruction-reordering IBC (RR-IBC) flip type of the block vector.

[0099] In some embodiments, if the luma block is RR-IBC coded, the block vector of the luma block is first adjusted by an offset before being inherited as the block vector for the chroma blocks. In some embodiments, the offset is determined based on the displacement relationship between the chroma block and the co-located luma block or luma sub-block. In some other embodiments, the offset is determined based on the flip type of the luma block coded by RR-IBC. In some embodiments, if the luma block is RR-IBC coded, the flip type of the luma block coded by RR-IBC is inherited to the chroma blocks.

[0100] In some embodiments, the predefined location (at Figure 30In the figure, A', B', C', ... F', H') include one or more other positions (in the figure) other than the center, upper left, upper right, lower left and lower right. Figure 30 In some embodiments, the predefined positions are one or more luma positions calculated based on at least one of the following positions of the chroma block: a center position between the top left and top right of the chroma block (e.g., between Figure 30 ” in the figure), the center position between the upper left and lower left of the chroma block (e.g., Figure 30 ” in the figure), the center position between the upper right and lower right of the chroma block (e.g., Figure 30 ” in the figure), the center position between the lower left and lower right of the chroma block (e.g., Figure 30 denoted as "D" in the figure), the middle of the upper left quarter of the chroma block (e.g., Figure 30 ), the middle of the upper right quarter of the chroma block (e.g., Figure 30 ), the middle of the lower left quarter of the chroma block (e.g., Figure 30 ) or the middle of the lower right quarter of the chroma block (e.g., Figure 30 Indicated as "H" in the figure).

[0101] In some embodiments, the block vectors for DBV mode and IBC mode are derived based on statistical information from the luma region corresponding to the chroma block. For example, the average block vector of the block vectors in the luma region is used for the chroma block. As another example, the block vector shared by the maximum luma sample region is used for the chroma block.

[0102] In some embodiments, whether to check the predefined position of the block vector used to derive the DBV mode for the chroma block depends on codec information of the video unit. In some embodiments, the codec information includes block dimensions of the chroma block. For example, the block dimensions include at least one of the following: the width of the chroma block or the height of the chroma block.

[0103] In some embodiments, the predefined position is checked if at least one of the width of the chroma block or the height of the chroma block is not less than or greater than a threshold. In some embodiments, the threshold is equal to one of the following: 4, 8, or 16.

[0104] In some embodiments, whether to check the predefined position depends on whether none of the block vectors obtained based on other sets of positions are valid. For example, the other sets of positions include one or more of the following: center position, upper left position, upper right position, lower left position, or lower right position.

[0105] In some embodiments, if none of the luma blocks derived based on the other group positions are encoded or decoded in at least one of IBC mode or intra TMP mode, then the predefined position is checked. In some embodiments, if none of the valid block vectors are derived based on the other group positions, then the predefined position is checked.

[0106] In some embodiments, the block vector candidates in the list of block vector candidates are derived based on predefined positions. In some other embodiments, the block vector candidates are derived based on a check rule. For example, the check rule includes traversing all NxN luma sub-blocks in the co-located luma block.

[0107] In some embodiments, which block vector candidate is used is indicated in the bitstream. In some other embodiments, which block vector candidate is used is derived by a decoder-side method.

[0108] In some embodiments, a chroma block is divided into chroma sub-blocks, and at least one of the following is derived for each chroma sub-block: a single codec mode for the chroma sub-block or a block vector for the chroma sub-block. For example, the codec mode includes an IBC mode or an RR-IBC mode. In some embodiments, the residuals of the multiple chroma sub-blocks are collectively transformed, quantized, or entropy encoded. In some other embodiments, the residuals of each chroma sub-block are individually transformed, quantized, or entropy encoded.

[0109] In some embodiments, the IBC prediction samples for the chroma block and the prediction samples from the second prediction mode are combined. In some embodiments, the second prediction mode is a cross-component mode. For example, the cross-component mode is a cross-component linear model (CCLM) mode or a convolutional cross-component model (CCCM) mode.

[0110] In some embodiments, the second prediction mode is an angular prediction mode. In some other embodiments, the IBC prediction samples and the prediction samples from the second prediction are weighted summed to generate a prediction for further processing. In some other embodiments, the IBC prediction samples and the prediction samples from the second prediction are combined in a manner defined by the SGPM.

[0111] In some embodiments, an implicit refinement process is applied to a block vector of a chroma block that is encoded and decoded in DBV mode. In some embodiments, a search region is defined. For example, the search region is defined as a displacement of a plurality of horizontal samples and a plurality of vertical samples. As an example, the search region is defined as a displacement of (+ / -M, + / -M) samples in the horizontal direction and (+ / -M, + / -M) samples in the vertical direction. In some embodiments, M is equal to 2.

[0112] In some embodiments, template matching-based refinement is applied during the implicit refinement process of the block vector. In some embodiments, the final refined block vector is determined based on a template cost of the template. For example, the template is constructed using the top and / or left neighboring samples adjacent to the chroma block and the reference block. For example, the template shape of the template is adjusted rightward and / or downward according to the RR-IBC flip type.

[0113] In some embodiments, an explicit refinement process is applied to the block vectors of chroma blocks that are encoded in DBV mode. For example, a block vector offset is applied on top of the block vector derived from the luma block.

[0114] In some embodiments, the offset candidates are predefined. For example, a list of offset candidates is defined in a table. In some embodiments, the offset candidates are indicated by an offset direction associated with an offset distance.

[0115] In some embodiments, the indication of the block vector offset is indicated in the bitstream. For example, the indication of the block vector offset is transmitted via a signal with an offset index. As another example, the indication of the block vector offset is transmitted via a signal with a direction index and a distance index.

[0116] In some embodiments, whether a block vector is valid for DBV mode depends on whether there are valid reference samples within the legal search region. In some other embodiments, whether a block vector is valid for DBV mode depends on the size of the valid reference region within the legal search region. For example, a threshold is defined to regulate the valid portion of the reference block within the legal search region.

[0117] In some embodiments, when a portion of the first reference block is within the legal search area, a first block vector (in Figure 31 Alternatively, when half of the first reference block exceeds the legal search area, the first block vector from the current block to the first reference block is considered invalid.

[0118] In some embodiments, when the entire area of ​​the second reference block is within the legal search area, the second block vector from the current block to the second reference block (in Figure 31 In some other embodiments, when the entire area of ​​the third reference block is within the legal search area, the third block vector from the current block to the third reference block (shown as BV1 in FIG. 1 ) is considered valid. Figure 31 is considered valid.

[0119] In some embodiments, the invalid area of ​​the reference block is filled with samples in the valid area of ​​the reference block. In some embodiments, filling the invalid area of ​​the reference block with samples in the valid area is based on repeated filling from a predefined order (e.g., from top to bottom, from bottom to top, from left to right, from right to left, etc.).

[0120] In some embodiments, if all block vectors for the available luma blocks are invalid for the chroma blocks, a fallback mode is used instead of the DBV mode. For example, if all block vectors for the available luma blocks are invalid for the chroma blocks, a linear model (LM) mode is used instead of the DBV mode. In some embodiments, the LM mode includes at least one of: LM-top left (LM-TL), LM-top (LM-T), or LM-left (LM-L).

[0121] In some embodiments, if all block vectors of the available luma blocks are invalid for the chroma blocks, a multi-model linear model (MMLM) mode is used instead of the DBV mode. For example, the MMLM mode includes at least one of the following: MMLM-top left (MMLM-TL), MMLM-top (MMLM-T), or MMLM-left (MMLM-L).

[0122] In some embodiments, if all block vectors of the available luma blocks are invalid for the chroma blocks, a convolutional cross-component model (CCCM) mode is used instead of the DBV mode. For example, the CCCM mode includes at least one of the following: CCCM-Top Left (CCCM-TL), CCCM-Top (CCCM-T), or CCCM-Left (CCCM-L).

[0123] In some embodiments, if all block vectors of the luminance block are invalid for the chrominance block, the gradient linear model (GLM) mode is used instead of the DBV mode. In this case, the chrominance fusion mode is further applied.

[0124] In some embodiments, the block vector of a chroma block is predicted by the block vectors of neighboring chroma blocks. In some other embodiments, block vector predictions or block vector candidates derived from neighboring chroma blocks are used together with block vectors derived from luma blocks.

[0125] For example, if a block vector derived from a luma block is not available, a block vector prediction or block vector candidate derived from a neighboring chroma block is used. As another example, if a block vector prediction or block vector candidate derived from a neighboring chroma block is not available, a block vector derived from a luma block is used. As an example, a block vector prediction or block vector candidate derived from a neighboring chroma block and a block vector derived from a luma block are placed in a single candidate list to be selected from.

[0126] In some embodiments, the decoder-derived intra mode is used to derive the transform kernel for the chroma block for DBV mode encoding. For example, the decoder-derived intra mode is based on neighboring samples of the chroma block.

[0127] In some embodiments, the decoder-derived intra mode is based on an intra mode based on a coded chroma block obtained from a block vector of the chroma block. In some other embodiments, the decoder-derived intra mode is based on neighboring samples of a co-located luma block.

[0128] In some embodiments, the decoder-derived intra mode is based on at least one of: predicted samples or reconstructed samples of a co-located luma block. In some other embodiments, the decoder-derived intra mode is based on an intra mode of a luma block within the co-located luma block.

[0129] In some embodiments, the intra-mode derived by the decoder is based on decoder-side intra-mode derivation (DIMD). In some other embodiments, the intra-mode derived by the decoder is based on template-based intra-mode derivation (TIMD). Alternatively, the intra-mode derived by the decoder is based on a gradient histogram.

[0130] In some embodiments, the LM mode is used to derive a transform kernel for a chroma block encoded in the DBV mode. For example, the LM mode includes at least one of the following: LM-TL, LM-T, or LM-L.

[0131] In some embodiments, the MMLM mode is used to derive a transform kernel for a chroma block encoded in DBV mode. For example, the MMLM mode includes at least one of the following: MMLM-TL, MMLM-T, or MMLM-L.

[0132] In some embodiments, the CCCM mode is used to derive a transform kernel for a chroma block encoded in DBV mode. For example, the CCCM mode includes at least one of the following: CCCM-TL, CCCM-T, or CCCM-L.

[0133] In some embodiments, the GLM mode is used to derive a transform kernel for chroma blocks encoded in DBV mode. In some embodiments, the transform kernel is one of the following: an MTS kernel, a LFNST kernel, a NSPT kernel, a separable transform kernel, an inseparable transform kernel, a primary transform kernel, or a secondary transform kernel.

[0134] In some embodiments, a syntax element (SE) is binarized as one of a flag, a fixed-length code, an EG(x) code, a unary code, a truncated unary code, or a truncated binary code. In some embodiments, the SE is signed or unsigned. In some embodiments, the SE is encoded or decoded using at least one context model, or the SE is bypassed for encoding or decoding. In some embodiments, the SE is signaled conditionally. In some embodiments, the SE is signaled only when a corresponding function is applicable. In some embodiments, the SE is indicated at one of the following: sequence level, group of pictures level, picture level, slice level, or slice group level.

[0135] In some embodiments, the SE is indicated at 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 codec tree block (CTB), or a codec tree unit (CTU). In some embodiments, the SE is indicated at 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 slice group header.

[0136] In some embodiments, an indication of whether and / or how to derive a block vector for a DBV mode for chroma blocks of a video unit is indicated at one of the following: sequence level, group of picture level, picture level, slice level, or slice group level. In some embodiments, an indication of whether and / or how to derive a block vector for a DBV mode for chroma blocks of a video unit 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 slice group header. In some embodiments, an indication of whether and / or how to derive a block vector for a DBV mode for chroma blocks of a video unit 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 codec tree block (CTB), or a codec tree unit (CTU).

[0137] In some embodiments, method 3200 further includes determining whether and / or how to derive a block vector for a DBV mode for a chroma block of the video unit based on codec information of the video unit, the codec information including at least one of: block size, color format, single and / or dual tree partitioning, color component, slice type, or picture type.

[0138] In some embodiments, the video unit is applied with another codec that requires chroma fusion.Conversion includes encoding the video unit into a bitstream and decoding the video unit from the bitstream.

[0139] According to another embodiment of the present disclosure, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium stores a bitstream of a video generated by a method performed by an apparatus for video processing. The method includes: deriving a block vector in a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of the following: a block vector for a luma block at a predefined position, a block vector for a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; and generating a bitstream based on the block vector in the DBV mode for the chroma block.

[0140] According to yet other embodiments of the present disclosure, a method for storing a bitstream of a video is provided. The method includes: deriving a block vector of a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of the following: a block vector of a luma block at a predefined position, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; generating a bitstream based on the block vector of the DBV mode for the chroma block; and storing the bitstream in a non-transitory computer-readable medium.

[0141] The embodiments of the present disclosure may be described according to the following items, the features of which may be combined in any reasonable way.

[0142] Item 1. A method of video processing, comprising: for conversion between a video unit of a video and a bitstream of the video unit, deriving a block vector of a direct block vector (DBV) mode for a chroma block of the video unit based on one of the following: a block vector of a luma block at a predefined position, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; and performing the conversion based on the block vector of the DBV mode for the chroma block.

[0143] Item 2. A method according to Item 1, wherein the block vector of each NxN luma sub-block of a co-located luma block that overlaps with an area of ​​the chroma block according to a downsampling rate is examined to derive the block vector of the DBV mode for the chroma block, where N is equal to 4 or 8.

[0144] Item 3. The method of Item 1, wherein the block vector of the DBV mode is derived based on a first available block vector of an NxN luma sub-block of a co-located luma block.

[0145] Item 4. A method according to Item 3, wherein whether the block vector of the NxN luminance sub-block of the co-located luminance block is available depends on whether the NxN sub-block is encoded and decoded using at least one of the following: intra block copy (IBC) mode or intra template matching prediction (intra TMP) mode.

[0146] Item 5. The method of Item 1, wherein the block vector of the DBV mode is derived based on a first valid block vector of an NxN luma sub-block of a co-located luma block.

[0147] Item 6. The method of Item 6, wherein whether a block vector of the NxN luma sub-block of the co-located luma block is valid depends on whether the block vector is within a valid search region of the DBV mode.

[0148] Clause 7. The method of clause 6, wherein the active search area is defined based on an active area for an IBC mode, or wherein the active search area is defined based on an active area for an intra TMP mode.

[0149] Item 8. The method of Item 1, wherein each basic unit in the luma region corresponding to the chroma block is checked sequentially.

[0150] Item 9. The method of Item 8, wherein the order is a raster scan.

[0151] Item 10. The method of Item 9, wherein the raster scan is from top left to bottom right, or wherein the raster scan is from bottom right to top left.

[0152] Item 11. The method of Item 9, wherein the raster scan is from top right to bottom left, or wherein the raster scan is from bottom left to top right.

[0153] Item 12. The method of Item 8, wherein the sequence is a spiral scan from the center to the periphery.

[0154] Item 13. The method according to Item 8, wherein the sequence is a spiral scan from the periphery to the center.

[0155] Item 14. The method of Item 8, wherein the sequence is a zigzag scan.

[0156] Item 15. The method of Item 1, wherein the block vector of the DBV mode is derived based on available block vectors or valid block vectors of all NxN luma sub-blocks of a co-located luma block.

[0157] Item 16. The method of Item 15, wherein which of all NxN luma sub-blocks is used to derive the block vector for the DBV mode is indicated in the bitstream.

[0158] Item 17. The method of Item 15, wherein which block of all NxN luma sub-blocks is used to derive the block vector for the DBV mode is derived by a decoder-side method.

[0159] Item 18. The method of Item 1, further comprising: deriving the block vector of the DBV mode for the chroma block based on the block vector of the chroma sub-block of MxM granularity, where M is an integer.

[0160] Item 19. The method according to Item 18, wherein M is equal to 2 or 4 or 8.

[0161] Item 20. A method according to Item 1, wherein the block vector obtained based on the predefined position is adjusted based on at least one of the following: a displacement relationship between the co-located chrominance block and the luminance block or the luminance sub-block, or a reconstruction-reordering IBC (RR-IBC) flip type of the block vector.

[0162] Item 21. The method of Item 20, wherein if the luma block is RR-IBC coded, the block vector of the luma block is first adjusted by an offset before being inherited as the block vector for the chroma block.

[0163] Item 22. The method of Item 21, wherein the offset is determined based on the displacement relationship between the chroma block and the co-located luma block or the luma sub-block.

[0164] Item 23. The method of Item 21, wherein the offset is determined based on a flip type of a luma block of the RR-IBC codec.

[0165] Item 24. The method of Item 20, wherein if the luma block is RR-IBC coded, the flip type of the RR-IBC coded luma block is inherited to the chroma blocks.

[0166] Item 25. The method of Item 1, wherein the predefined positions include one or more other positions besides the center, upper left, upper right, lower left, and lower right.

[0167] Item 26. A method according to Item 1, wherein the predefined position is one or more luminance positions calculated based on at least one of the following positions of the chrominance block: the center position between the upper left and upper right of the chrominance block, the center position between the upper left and lower left of the chrominance block, the center position between the upper right and lower right of the chrominance block, the center position between the lower left and lower right of the chrominance block, the middle position of the upper left quarter area of ​​the chrominance block, the middle position of the upper right quarter area of ​​the chrominance block, the middle position of the lower left quarter area of ​​the chrominance block, or the middle position of the lower right quarter area of ​​the chrominance block.

[0168] Item 27. The method of Item 1, wherein the block vector for the DBV mode and the block vector for the IBC mode are derived based on statistical information from a luma region corresponding to the chroma block.

[0169] Item 28. The method of Item 27, wherein an average block vector of block vectors in the luma region is used for the chroma block.

[0170] Item 29. The method of Item 27, wherein a block vector shared by a maximum luma sample region is used for the chroma blocks.

[0171] Item 30. The method of Item 1, wherein whether to check the predefined position of the block vector used to derive the DBV mode for the chroma block depends on codec information of the video unit.

[0172] Item 31. The method of Item 30, wherein the codec information comprises block dimensions of the chroma block, and the block dimensions comprise at least one of: a width of the chroma block or a height of the chroma block.

[0173] Item 32. The method of Item 31, wherein the predefined position is checked if at least one of the width of the chroma block or the height of the chroma block is not less than or greater than a threshold.

[0174] Item 33. The method of Item 32, wherein the threshold is equal to one of: 4, 8, or 16.

[0175] Item 34. The method of Item 1, wherein whether to check the predefined position depends on whether none of the block vectors obtained based on other sets of positions are valid.

[0176] Item 35. The method of Item 34, wherein the other group positions include one or more of: a center position, an upper left position, an upper right position, a lower left position, or a lower right position.

[0177] Item 36. The method of Item 34, wherein the predefined position is checked if none of the luma blocks derived based on the other set of positions are encoded or decoded in at least one of IBC mode or Intra TMP mode.

[0178] Item 37. The method of Item 34, wherein the predefined position is checked if none of the valid block vectors are derived based on the other set of positions.

[0179] Item 38. The method of Item 1, wherein the block vector candidates in the list of block vector candidates are derived based on the predefined positions.

[0180] Item 39. The method of Item 38, wherein the block vector candidates are derived based on a checking rule.

[0181] Item 40. The method of Item 39, wherein the checking rule comprises traversing all NxN luma sub-blocks in a co-located luma block.

[0182] Item 41. The method of Item 38, wherein which block vector candidate is used is indicated in the bitstream.

[0183] Item 42. The method of Item 38, wherein which block vector candidate is used is derived by a decoder-side method.

[0184] Item 43. The method of Item 1, wherein the chroma block is divided into chroma sub-blocks, and each chroma sub-block derives at least one of: a single codec mode for the chroma sub-block or a block vector for the chroma sub-block.

[0185] Item 44. The method of Item 43, wherein the codec mode comprises an IBC mode or a RR-IBC mode.

[0186] Item 45. The method of Item 44, wherein the residuals of the plurality of chroma sub-blocks are collectively transformed or quantized or entropy coded.

[0187] Item 46. The method of Item 44, wherein the residual of each chroma subblock is individually transformed or quantized or entropy coded.

[0188] Item 47. The method of Item 1, wherein for the chroma block IBC prediction samples and prediction samples from a second prediction mode are combined.

[0189] Item 48. The method of Item 47, wherein the second prediction mode is an inter-component mode.

[0190] Item 49. The method of Item 48, wherein the cross-component mode is a cross-component linear model (CCLM) mode or a convolutional cross-component model (CCCM) mode.

[0191] Item 50. The method of Item 47, wherein the second prediction mode is an angular prediction mode.

[0192] Item 51. The method of Item 47, wherein the IBC prediction samples and the prediction samples from the second prediction are weighted summed to generate a prediction for further processing.

[0193] Item 52. The method of Item 47, wherein the IBC prediction samples and the prediction samples from the second prediction are combined in a manner defined by a Spatial Geometry Partitioning Mode (SGPM).

[0194] Item 53. The method of Item 1, wherein an implicit refinement process is applied to the block vector of the chroma block, the chroma block being encoded and decoded in DBV mode.

[0195] Item 54. The method of Item 53, wherein a search area is defined.

[0196] Item 55. The method according to Item 54, wherein the search area is defined as a displacement having a plurality of horizontal sample points and a plurality of vertical sample points, respectively.

[0197] Item 56. The method of Item 54, wherein the search area is defined as having a displacement of (+ / -M, + / -M) samples in the horizontal direction and (+ / -M, + / -M) samples in the vertical direction, respectively.

[0198] Item 57. The method of Item 56, wherein M is equal to 2.

[0199] Item 58. The method of Item 53, wherein template matching based refinement is applied during the implicit refinement process of the block vector.

[0200] Item 59. The method of Item 53, wherein the final refined block vector is determined based on a template cost of the template.

[0201] Item 60. The method of Item 59, wherein the template is constructed by top and / or left neighboring samples adjacent to the chroma block and reference block.

[0202] Item 61. The method according to Item 59, wherein the template shape of the template is adjusted rightward and / or downward according to the RR-IBC flip type.

[0203] Item 62. The method of Item 1, wherein an explicit refinement process is applied to the block vector of the chroma block, the chroma block being encoded in DBV mode.

[0204] Item 63. The method of Item 62, wherein a block vector offset is applied on top of the block vector derived from the luma block.

[0205] Item 64. A method according to item 63, wherein the offset candidates are predefined.

[0206] Item 65. A method according to item 64, wherein the list of offset candidates is defined in a table.

[0207] Item 66. The method of Item 64, wherein the offset candidate is indicated by an offset direction associated with an offset distance.

[0208] Item 67. The method of Item 63, wherein an indication of the block vector offset is indicated in the bitstream.

[0209] Item 68. The method of Item 67, wherein the indication of the block vector offset is signaled as an offset index.

[0210] Item 69. The method of Item 67, wherein the indication of the block vector offset is signaled as a direction index and a distance index.

[0211] Item 70. The method of Item 1, wherein whether a block vector is valid for the DBV mode depends on whether a valid reference sample exists within a legal search region.

[0212] Item 71. The method of Item 1, wherein whether a block vector is valid for the DBV mode depends on the size of a valid reference region within a legal search region.

[0213] Item 72. The method of Item 71, wherein a threshold is defined to adjust the effective portion of the reference block within the legal search zone.

[0214] Item 73. The method of Item 1, wherein a first block vector from a current block to a first reference block is considered valid when a portion of the first reference block is within a legal search area.

[0215] Item 74. The method of Item 1, wherein a first block vector from a current block to the first reference block is deemed invalid when half of the first reference block exceeds a legal search area.

[0216] Item 75. The method of Item 1, wherein a second block vector from the current block to the second reference block is deemed valid when the entire area of ​​the second reference block is within the legal search area.

[0217] Item 76. The method of Item 1, wherein a third block vector from the current block to the third reference block is deemed valid when the entire area of ​​the third reference block is within the legal search area.

[0218] Item 77. The method of Item 1, wherein an invalid area of ​​a reference block is filled with samples in a valid area of ​​the reference block.

[0219] Item 78. The method of Item 77, wherein filling the invalid area of ​​the reference block with samples in the valid area is based on repeated padding from a predefined order.

[0220] Item 79. The method of Item 1, wherein if all block vectors of the available luma blocks for the chroma blocks are invalid, a fallback mode is used instead of the DBV mode.

[0221] Item 80. The method of Item 79, wherein if all block vectors of the available luma blocks for the chroma blocks are invalid, a linear model (LM) mode is used instead of the DBV mode.

[0222] Item 81. The method of Item 80, wherein the LM mode comprises at least one of: LM-Top-Left (LM-TL), LM-Top (LM-T), or LM-Left (LM-L).

[0223] Item 82. The method of Item 79, wherein if all block vectors of the available luma blocks for the chroma blocks are invalid, a multi-model linear model (MMLM) mode is used instead of the DBV mode.

[0224] Item 83. The method of Item 82, wherein the MMLM mode comprises at least one of: MMLM-Top-Left (MMLM-TL), MMLM-Top (MMLM-T), or MMLM-Left (MMLM-L).

[0225] Item 84. The method of Item 79, wherein if all block vectors of the available luma blocks for the chroma blocks are invalid, a convolutional cross-component model (CCCM) mode is used instead of the DBV mode.

[0226] Item 85. The method of Item 84, wherein the CCCM mode comprises at least one of: CCCM-Top-Left (CCCM-TL), CCCM-Top (CCCM-T), or CCCM-Left (CCCM-L).

[0227] Item 86. The method of Item 79, wherein if all block vectors of the available luma blocks for the chroma blocks are invalid, a gradient linear model (GLM) mode is used instead of the DBV mode.

[0228] Item 87. A method according to any one of Items 80 to 86, wherein a chroma fusion mode is further applied.

[0229] Item 88. The method of Item 1, wherein the block vector of the chroma block is predicted by block vectors of neighboring chroma blocks.

[0230] Item 89. The method of Item 1, wherein a block vector prediction or block vector candidate derived from a neighboring chroma block is used together with a block vector derived from the luma block.

[0231] Item 90. The method of Item 1, wherein if a block vector derived from the luma block is not available, a block vector prediction or block vector candidate derived from a neighboring chroma block is used.

[0232] Item 91. The method of Item 1, wherein a block vector derived from the luma block is used if a block vector prediction or block vector candidate derived from a neighboring chroma block is not available.

[0233] Item 92. The method of Item 1, wherein block vector predictions or block vector candidates derived from neighboring chroma blocks and a block vector derived from the luma block are placed in a single candidate list to be selected from.

[0234] Item 93. The method of Item 1, wherein decoder-derived intra modes are used to derive transform kernels for chroma blocks encoded for DBV mode.

[0235] Item 94. The method of Item 93, wherein the decoder-derived intra mode is based on neighboring samples of the chroma block.

[0236] Item 95. The method of Item 93, wherein the decoder-derived intra-mode is based on an intra-mode based on an encoded chroma block obtained from the block vector of the chroma block.

[0237] Item 96. The method of Item 93, wherein the decoder derives an intra mode based on neighboring samples of a co-located luma block.

[0238] Item 97. The method of Item 93, wherein the intra mode derived by the decoder is based on at least one of: predicted samples or reconstructed samples of a co-located luma block.

[0239] Item 98. The method of Item 93, wherein the decoder-derived intra mode is based on an intra mode of a luma block within a co-located luma block.

[0240] Item 99. The method of Item 93, wherein the decoder-derived intra-mode is based on decoder-side intra-mode derivation (DIMD).

[0241] Item 100. The method of Item 93, wherein the decoder-derived intra-mode is based on template-based intra-mode derivation (TIMD).

[0242] Item 101. The method of Item 93, wherein the decoder-derived intra mode is based on a gradient histogram.

[0243] Item 102. The method of Item 1, wherein the LM mode is used to derive the transform kernel for chroma blocks encoded in DBV mode.

[0244] Item 103. The method of Item 102, wherein the LM mode comprises at least one of: LM-TL, LM-T, or LM-L.

[0245] Item 104. The method of Item 1, wherein the MMLM mode is used to derive the transform kernel for chroma blocks for DBV mode encoding.

[0246] Item 105. The method of Item 104, wherein the MMLM mode comprises at least one of: MMLM-TL, MMLM-T, or MMLM-L.

[0247] Item 106. The method of Item 1, wherein the CCCM mode is used to derive the transform kernel for chroma blocks encoded in DBV mode.

[0248] Item 107. The method of Item 106, wherein the CCCM mode comprises at least one of: CCCM-TL, CCCM-T, or CCCM-L.

[0249] Item 108. The method of Item 1, wherein the GLM mode is used to derive the transform kernel for chroma blocks encoded in DBV mode.

[0250] Item 109. The method according to any one of Items 93 to 108, wherein the transform kernel is one of the following: an MTS kernel, a LFNST kernel, a NSPT kernel, a separable transform kernel, an inseparable transform kernel, a primary transform kernel, or a secondary transform kernel.

[0251] Item 110. The method of any one of items 1 to 109, wherein the syntax element (SE) is binarized as one of a flag, a fixed length code, an EG(x) code, a unary code, a truncated unary code, or a truncated binary code.

[0252] Item 111. The method of Item 110, wherein the SE is signed or unsigned.

[0253] Item 112. A method according to any one of items 1 to 111, wherein the SE is encoded and decoded using at least one context model, or wherein the SE is bypass encoded and decoded.

[0254] Item 113. A method according to any one of Items 1 to 112, wherein the SE is signaled in a conditional manner.

[0255] Item 114. The method of Item 112, wherein the SE is transmitted via a signal only when the corresponding function is applicable.

[0256] Item 115. The method of any one of Items 1 to 114, wherein the SE is indicated at one of: sequence level, group of pictures level, picture level, slice level, or slice group level.

[0257] Item 116. A method according to any one of items 1 to 114, wherein the SE is indicated at 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 codec tree block (CTB), or a codec tree unit (CTU).

[0258] Item 117. A method according to any one of Items 1 to 114, wherein the SE is indicated at 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 slice group header.

[0259] Item 118. A method according to any one of Items 1 to 117, wherein an indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit is indicated at one of: sequence level, picture group level, picture level, slice level, or slice group level.

[0260] Item 119. A method according to any one of Items 1 to 117, wherein an indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit 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 slice group header.

[0261] Item 120. A method according to any one of Items 1 to 117, wherein the indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit 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 codec tree block (CTB), or a codec tree unit (CTU).

[0262] Item 121. The method according to any one of Items 1 to 117 further includes: determining whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit based on codec information of the video unit, the codec information including at least one of the following: block size, color format, single and / or double tree partitioning, color component, slice type, or picture type.

[0263] Item 122. The method of any one of Items 1 to 121, wherein the video unit is applied together with another codec requiring chroma fusion.

[0264] Item 123. The method of any one of Items 1 to 122, wherein the converting comprises encoding the video unit into the bitstream.

[0265] Item 124. The method of any one of Items 1 to 122, wherein the converting comprises decoding the video unit from the bitstream.

[0266] Item 125. An apparatus for video processing, comprising a processor and non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to perform the method of any one of items 1 to 124.

[0267] Item 126. A non-transitory computer-readable storage medium storing instructions for causing a processor to perform the method according to any one of Items 1 to 124.

[0268] Item 127. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by an apparatus for video processing, wherein the method comprises: deriving a block vector of a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of: a block vector of a luma block at a predefined position, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; and generating the bitstream based on the block vector of the DBV mode for the chroma block.

[0269] Item 128. A method for storing a bitstream of a video, comprising: deriving a block vector of a direct block vector (DBV) mode for a chroma block of a video unit of the video based on one of: a block vector of a luma block at a predefined position, a block vector of a luma sub-block of NxN granularity, where N is an integer, or a list of block vector candidates; generating the bitstream based on the block vector of the DBV mode for the chroma block, and storing the bitstream in a non-transitory computer-readable medium. Example device

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

[0271] It should be understood that Figure 33 The computing device 3300 shown in FIG. 3 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.

[0272] like Figure 33 As shown, computing device 3300 includes a general computing device 3300. Computing device 3300 may include at least one or more processors or processing units 3310, memory 3320, storage unit 3330, one or more communication units 3340, one or more input devices 3350, and one or more output devices 3360.

[0273] In some embodiments, the computing device 3300 can be implemented as any user terminal or server terminal with computing power. The server terminal can be a server, a large computing device, etc. provided by a service provider. The user terminal can be, for example, any type of mobile terminal, fixed terminal, or portable terminal, including 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 tablet 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, including accessories and peripherals of these devices, or any combination thereof. It is conceivable that the computing device 3300 can support any type of interface to the user (such as a "wearable" circuit device, etc.).

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

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

[0276] The computing device 3300 may also include additional removable / non-removable storage media, volatile / non-volatile storage media. Figure 33 Although not shown, 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 a bus (not shown) via one or more data medium interfaces.

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

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

[0279] In some embodiments, some or all components of the computing device 3300 may also be arranged in a cloud computing architecture rather than being integrated into a single device. In a cloud computing architecture, components can be provided remotely and work together to implement the functionality described in this disclosure. In some embodiments, cloud computing provides computing, software, data access, and storage services without requiring the end user to know the physical location or configuration of the systems or hardware providing these services. In various embodiments, cloud computing provides services via a wide area network (such as the Internet) using appropriate protocols. For example, a cloud computing provider provides an application via a wide area network that 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 can be stored on servers in a remote location. Computing resources in a cloud computing environment can be consolidated or distributed across remote data centers. Cloud computing infrastructure can provide services through shared data centers, although to users, they appear as a single access point. Therefore, cloud computing architecture can be used to provide the components and functionality described herein from a service provider in a remote location. Alternatively, the components and functionality described herein can be provided by a conventional server or installed directly or otherwise on a client device.

[0280] In an embodiment of the present disclosure, the computing device 3300 may be used to implement video encoding / decoding. The memory 3320 may include one or more video encoding / decoding modules 3325 having one or more program instructions. These modules are accessible and executable by the processing unit 3310 to perform the functions of the various embodiments described herein.

[0281] In an example embodiment performing video encoding, input device 3350 may receive video data as input to be encoded 3370. The video data may be processed, for example, by video codec module 3325 to generate an encoded bitstream. The encoded bitstream may be provided as output 3380 via output device 3360.

[0282] In an example embodiment performing video decoding, input device 3350 may receive an encoded bitstream as input 3370. The encoded bitstream may be processed, for example, by video codec module 3325 to generate decoded video data. The decoded video data may be provided as output 3380 via output device 3360.

[0283] 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 in form and details may be made without departing from the spirit and scope of the present application as defined by the appended claims. Such variations 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 unit, deriving a block vector in a direct block vector (DBV) mode for a chroma block of the video unit based on one of: the block vector of the luma block at a predefined position, A block vector for a luma subblock of NxN granularity, where N is an integer, or a list of block vector candidates; as well as The converting is performed based on the block vector of the DBV mode for the chroma block.

2. The method of claim 1 , wherein a block vector of each NxN luma sub-block of a co-located luma block that overlaps with an area of ​​the chroma block according to a downsampling rate is examined to derive the block vector of the DBV mode for the chroma block, where N is equal to 4 or 8. 3 . The method of claim 1 , wherein the block vector of the DBV mode is derived based on a first available block vector of an N×N luma sub-block of a co-located luma block.

4. The method of claim 3 , wherein whether the block vector of the NxN luma sub-block of the co-located luma block is available depends on whether the NxN sub-block is encoded or decoded using at least one of: intra block copy (IBC) mode or intra template matching prediction (intra TMP) mode. 5 . The method of claim 1 , wherein the block vector of the DBV mode is derived based on a first valid block vector of an N×N luma sub-block of a co-located luma block.

6. The method of claim 6, wherein whether a block vector of the NxN luma sub-block of the co-located luma block is valid depends on whether the block vector is within a valid search area of ​​the DBV mode.

7. The method of claim 6, wherein the valid search area is defined based on a valid area for an IBC mode, or The effective search area is defined based on the effective area for the intra TMP mode. The method of claim 1 , wherein each basic unit in a luma region corresponding to the chroma block is checked in sequence.

9. The method of claim 8, wherein the sequence is a raster scan.

10. The method of claim 9, wherein the raster scan is from upper left to lower right, or The raster scan is from the lower right to the upper left.

11. The method of claim 9, wherein the raster scan is from upper right to lower left, or The raster scan is from the lower left to the upper right.

12. The method of claim 8, wherein the sequence is a spiral scan from the center to the periphery.

13. The method of claim 8, wherein the sequence is a spiral scan from the periphery to the center. The method of claim 8 , wherein the sequence is a zigzag scan.

15. The method of claim 1, wherein the block vector of the DBV mode is derived based on available block vectors or valid block vectors of all NxN luma sub-blocks of a co-located luma block.

16. The method of claim 15, wherein which of all NxN luma sub-blocks is used to derive the block vector for the DBV mode is indicated in the bitstream.

17. The method of claim 15, wherein which block among all NxN luma sub-blocks is used to derive the block vector for the DBV mode is derived by a decoder-side method.

18. The method of claim 1, further comprising: The block vector of the DBV mode for the chroma block is derived based on the block vector of the chroma sub-block with MxM granularity, where M is an integer. The method according to claim 18 , wherein M is equal to 2 or 4 or 8.

20. The method of claim 1, wherein the block vector obtained based on the predefined position is adjusted based on at least one of: a displacement relationship between a co-located chroma block and the luminance block or the luminance sub-block, or a reconstruction-reordering IBC (RR-IBC) flip type of the block vector.

21. The method of claim 20, wherein if the luma block is RR-IBC coded, the block vector of the luma block is first adjusted by an offset before being inherited as the block vector for the chroma block.

22. The method of claim 21, wherein the offset is determined based on the displacement relationship between the chroma block and the co-located luma block or the luma sub-block.

23. The method of claim 21, wherein the offset is determined based on a flip type of a luma block of the RR-IBC codec.

24. The method of claim 20, wherein if the luma block is RR-IBC coded, a flip type of the RR-IBC coded luma block is inherited to the chroma block.

25. The method of claim 1, wherein the predefined positions include one or more other positions besides center, upper left, upper right, lower left, and lower right.

26. The method of claim 1, wherein the predefined positions are one or more luma positions calculated based on at least one of the following positions of the chroma block: The center position between the upper left and upper right of the chroma block, The center position between the upper left and lower left of the chroma block, The center position between the upper right and lower right of the chroma block, The center position between the lower left and lower right of the chroma block, The middle position of the upper left quarter of the chroma block, The middle position of the upper right quarter of the chroma block, the middle of the lower left quarter of the chroma block, or The middle of the lower right quarter of the chroma block.

27. The method of claim 1, wherein the block vector of the DBV mode and the block vector of the IBC mode are derived based on statistical information from a luma region corresponding to the chroma block.

28. The method of claim 27, wherein an average block vector of block vectors in the luma region is used for the chroma block.

29. The method of claim 27, wherein a block vector shared by a maximum luma sample area is used for the chroma blocks.

30. The method of claim 1, wherein whether to check the predefined position of the block vector used to derive the DBV mode for the chroma block depends on codec information of the video unit.

31. The method of claim 30, wherein the codec information comprises block dimensions of the chroma block, and the block dimensions comprise at least one of: a width of the chroma block or a height of the chroma block.

32. The method of claim 31, wherein the predefined position is checked if at least one of the width of the chroma block or the height of the chroma block is not less than or greater than a threshold.

33. The method of claim 32, wherein the threshold is equal to one of: 4, 8, or 16.

34. The method of claim 1, wherein whether to check the predefined position depends on whether none of the block vectors obtained based on other sets of positions are valid.

35. The method of claim 34, wherein the other set of positions includes one or more of: a center position, an upper left position, an upper right position, a lower left position, or a lower right position.

36. The method of claim 34, wherein the predefined position is checked if none of the luma blocks derived based on the other set of positions are encoded in at least one of IBC mode or Intra TMP mode.

37. The method of claim 34, wherein the predefined position is checked if none of the valid block vectors are derived based on the other set of positions.

38. The method of claim 1, wherein block vector candidates in the list of block vector candidates are derived based on the predefined positions.

39. The method of claim 38, wherein the block vector candidates are derived based on a checking rule.

40. The method of claim 39, wherein the checking rule comprises traversing all NxN luma sub-blocks in a co-located luma block.

41. The method of claim 38, wherein which block vector candidate is used is indicated in the bitstream.

42. The method of claim 38, wherein which block vector candidate is used is derived by a decoder-side method.

43. The method of claim 1, wherein the chroma block is divided into chroma sub-blocks, and each chroma sub-block derives at least one of the following: a single codec mode for the chroma sub-block or a block vector for the chroma sub-block. The method according to claim 43 , wherein the codec mode comprises an IBC mode or a RR-IBC mode.

45. The method according to claim 44, wherein the residuals of the plurality of chroma sub-blocks are transformed or quantized or entropy coded as a whole.

46. ​​The method of claim 44, wherein the residual of each chroma sub-block is individually transformed or quantized or entropy coded.

47. The method of claim 1, wherein for the chroma block IBC prediction samples and prediction samples from a second prediction mode are combined.

48. The method of claim 47, wherein the second prediction mode is an inter-component mode.

49. The method of claim 48, wherein the cross-component mode is a cross-component linear model (CCLM) mode or a convolutional cross-component model (CCCM) mode.

50. The method of claim 47, wherein the second prediction mode is an angular prediction mode.

51. The method of claim 47, wherein the IBC prediction samples and the prediction samples from the second prediction are weighted summed to generate a prediction for further processing.

52. The method of claim 47, wherein the IBC prediction samples and the prediction samples from the second prediction are combined in a manner defined by a Spatial Geometry Partitioning Mode (SGPM).

53. The method of claim 1, wherein an implicit refinement process is applied to the block vector of the chroma block, the chroma block being encoded in DBV mode.

54. The method of claim 53, wherein a search area is defined.

55. The method of claim 54, wherein the search area is defined as a displacement having a plurality of horizontal and vertical sample points, respectively.

56. The method of claim 54, wherein the search area is defined as having a displacement of (+ / -M, + / -M) samples in a horizontal direction and (+ / -M, + / -M) samples in a vertical direction, respectively.

57. The method of claim 56, wherein M is equal to 2.

58. The method of claim 53, wherein template matching based refinement is applied during the implicit refinement process of the block vector.

59. The method of claim 53, wherein the final refined block vector is determined based on a template cost of the template.

60. The method of claim 59, wherein the template is constructed by top and / or left neighboring samples adjacent to the chroma block and reference block.

61. The method of claim 59, wherein the template shape of the template is adjusted rightward and / or downward according to the RR-IBC flip type.

62. The method of claim 1, wherein an explicit refinement process is applied to the block vector of the chroma block, the chroma block being encoded in DBV mode.

63. The method of claim 62, wherein a block vector offset is applied on top of the block vector derived from the luma block. The method of claim 63 , wherein the offset candidates are predefined.

65. A method according to claim 64, wherein the list of offset candidates is defined in a table.

66. The method of claim 64, wherein the offset candidate is indicated by an offset direction associated with an offset distance.

67. The method of claim 63, wherein an indication of the block vector offset is indicated in the bitstream.

68. The method of claim 67, wherein the indication of the block vector offset is signaled as an offset index.

69. The method of claim 67, wherein the indication of the block vector offset is signaled as a direction index and a distance index.

70. The method of claim 1, wherein whether a block vector is valid for the DBV mode depends on whether a valid reference sample exists within a legal search region.

71. The method of claim 1, wherein whether a block vector is valid for the DBV mode depends on a size of a valid reference region within a legal search region.

72. The method of claim 71, wherein a threshold is defined to adjust the valid portion of the reference block within the legal search zone.

73. The method of claim 1, wherein a first block vector from a current block to a first reference block is considered valid when a portion of the first reference block is within a legal search region.

74. The method of claim 1, wherein a first block vector from a current block to a first reference block is deemed invalid when half of the first reference block exceeds a legal search area.

75. The method of claim 1, wherein a second block vector from a current block to the second reference block is considered valid when the entire area of ​​the second reference block is within a legal search area.

76. The method of claim 1, wherein a third block vector from a current block to a third reference block is considered valid when the entire area of ​​the third reference block is within a legal search area.

77. The method of claim 1, wherein an invalid area of ​​a reference block is filled with samples in a valid area of ​​the reference block.

78. The method of claim 77, wherein filling the invalid area of ​​the reference block with samples in the valid area is based on repeated padding from a predefined order.

79. The method of claim 1, wherein a fallback mode is used instead of the DBV mode if all block vectors of available luma blocks are invalid for the chroma blocks.

80. The method of claim 79, wherein if all block vectors of available luma blocks are invalid for the chroma blocks, a linear model (LM) mode is used instead of the DBV mode.

81. The method of claim 80, wherein the LM mode comprises at least one of: LM-Top-Left (LM-TL), LM-Top (LM-T), or LM-Left (LM-L).

82. The method of claim 79, wherein if all block vectors of available luma blocks are invalid for the chroma blocks, a Multiple Model Linear Model (MMLM) mode is used instead of the DBV mode.

83. The method of claim 82, wherein the MMLM mode comprises at least one of: MMLM-Top-Left (MMLM-TL), MMLM-Top (MMLM-T), or MMLM-Left (MMLM-L).

84. The method of claim 79, wherein if all block vectors of a luma block are invalid for the chroma block, a convolutional cross-component model (CCCM) mode is used instead of the DBV mode.

85. The method of claim 84, wherein the CCCM mode comprises at least one of: CCCM-Top-Left (CCCM-TL), CCCM-Top (CCCM-T), or CCCM-Left (CCCM-L).

86. The method of claim 79, wherein if all block vectors of available luma blocks are invalid for the chroma blocks, a gradient linear model (GLM) mode is used instead of the DBV mode.

87. The method according to any one of claims 80 to 86, wherein a chroma blending mode is further applied.

88. The method of claim 1, wherein the block vector of the chroma block is predicted by block vectors of neighboring chroma blocks.

89. The method of claim 1, wherein block vector predictions or block vector candidates derived from neighboring chroma blocks are used together with the block vector derived from the luma block.

90. The method of claim 1, wherein if a block vector derived from the luma block is not available, a block vector prediction or block vector candidate derived from a neighboring chroma block is used.

91. The method of claim 1, wherein a block vector derived from the luma block is used if a block vector prediction or block vector candidate derived from a neighboring chroma block is not available.

92. The method of claim 1, wherein block vector predictions or block vector candidates derived from neighboring chroma blocks and a block vector derived from the luma block are placed in a single candidate list to be selected from.

93. The method of claim 1, wherein decoder-derived intra modes are used to derive transform kernels for chroma blocks encoded in DBV mode.

94. The method of claim 93, wherein the decoder-derived intra mode is based on neighboring samples of the chroma block.

95. The method of claim 93, wherein the decoder-derived intra-mode is based on an intra-mode based on an encoded chroma block obtained from the block vector of the chroma block.

96. The method of claim 93, wherein the decoder derives an intra mode based on neighboring samples of a co-located luma block.

97. The method of claim 93, wherein the decoder-derived intra mode is based on at least one of: predicted samples or reconstructed samples of a co-located luma block.

98. The method of claim 93, wherein the decoder-derived intra-mode is based on an intra-mode of a luma block within a co-located luma block.

99. The method of claim 93, wherein the decoder-derived intra-mode is based on decoder-side intra-mode derivation (DIMD).

100. The method of claim 93, wherein the decoder-derived intra-mode is based on template-based intra-mode derivation (TIMD).

101. The method of claim 93, wherein the decoder-derived intra-mode is based on a histogram of gradients.

102. The method of claim 1, wherein the LM mode is used to derive the transform kernel for chroma blocks encoded in DBV mode.

103. The method of claim 102, wherein the LM mode comprises at least one of: LM-TL, LM-T, or LM-L.

104. The method of claim 1, wherein the MMLM mode is used to derive the transform kernel for chroma blocks for DBV mode encoding and decoding.

105. The method of claim 104, wherein the MMLM mode comprises at least one of: MMLM-TL, MMLM-T, or MMLM-L.

106. The method of claim 1, wherein CCCM mode is used to derive transform kernels for chroma blocks for DBV mode encoding and decoding.

107. The method of claim 106, wherein the CCCM mode comprises at least one of: CCCM-TL, CCCM-T, or CCCM-L.

108. The method of claim 1, wherein the GLM mode is used to derive the transform kernel for chroma blocks encoded in DBV mode.

109. The method of any one of claims 93 to 108, wherein the transform kernel is one of: MTS core, LFNST core, NSPT nucleus, Separable transformation kernel, Inseparable transformation kernel, The main transform core, or Quadratic transform kernel.

110. The method according to any one of claims 1 to 109, wherein a syntax element (SE) is binarized as one of a flag, a fixed length code, an EG(x) code, a unary code, a truncated unary code or a truncated binary code.

111. The method of claim 110, wherein the SE is signed or unsigned.

112. The method according to any one of claims 1 to 111, wherein the SE is encoded or decoded using at least one context model, or The SE is bypassed for coding.

113. The method according to any one of claims 1 to 112, wherein the SE is signaled in a conditional manner.

114. The method of claim 112, wherein the SE is transmitted via a signal only when the corresponding function is applicable.

115. The method of any one of claims 1 to 114, wherein the SE is indicated at one of: Sequence level, Picture group level, Picture level, Stripe level, or Film group level.

116. The method of any one of claims 1 to 114, wherein the SE is indicated at one of: Prediction Block (PB), Transform Block (TB), Codec Block (CB), Prediction Unit (PU), Transformation Unit (TU), Codec Unit (CU), Codec Tree Block (CTB), or Codec Tree Unit (CTU).

117. The method of any one of claims 1 to 114, wherein the SE is indicated at one of: 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 Film group header.

118. The method of any one of claims 1 to 117, wherein an indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit is indicated at one of: Sequence level, Picture group level, Picture level, Stripe level, or Film group level.

119. The method of any one of claims 1 to 117, wherein an indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit is indicated in one of: 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 Film group header.

120. The method of any one of claims 1 to 117, wherein an indication of whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit is included in one of: Prediction Block (PB), Transform Block (TB), Codec Block (CB), Prediction Unit (PU), Transformation Unit (TU), Codec Unit (CU), Codec Tree Block (CTB), or Codec Tree Unit (CTU).

121. The method according to any one of claims 1 to 117, further comprising: determining whether and / or how to derive the block vector of the DBV mode for the chroma block of the video unit based on codec information of the video unit, the codec information comprising at least one of the following: Block size, Color format, Single and / or double tree partitioning, Color component, Strip type, or Image type.

122. The method according to any one of claims 1 to 121, wherein the video unit is applied together with another codec requiring chroma blending.

123. The method of any one of claims 1 to 122, wherein the converting comprises encoding the video unit into the bitstream.

124. The method of any one of claims 1 to 122, wherein the converting comprises decoding the video unit from the bitstream.

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

126. A non-transitory computer-readable storage medium storing instructions for causing a processor to perform the method according to any one of claims 1 to 124.

127. A non-transitory computer-readable recording medium storing a bitstream of a video generated by a method performed by an apparatus for video processing, wherein the method comprises: A block vector for a direct block vector (DBV) mode of a chroma block of a video unit of the video is derived based on one of: the block vector of the luma block at a predefined position, A block vector for a luma subblock of NxN granularity, where N is an integer, or a list of block vector candidates; as well as The bitstream is generated based on the block vector of the DBV mode for the chroma block.

128. A method for storing a bitstream of a video, comprising: A block vector for a direct block vector (DBV) mode of a chroma block of a video unit of the video is derived based on one of: the block vector of the luma block at a predefined position, A block vector for a luma subblock of NxN granularity, where N is an integer, or a list of block vector candidates; generating the bitstream based on the block vector of the DBV mode for the chroma block, and The bitstream is stored in a non-transitory computer-readable medium.

Images