Minimum allowed quantization of transform skip blocks in video codecs

Abstract

A method of video processing includes performing conversion between a video including a video region and a bitstream of the video according to a rule, and wherein the rule specifies a relationship between enabling of a palette mode and a codec type of the video region. The video region may represent a codec block of the video.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is filed in accordance with patent laws and / or rules applicable to the Paris Convention to timely claim priority and the benefit of International Patent Application No. PCT / CN2020 / 084291 filed on April 10, 2020. The entire disclosure of the above application is incorporated by reference as part of the disclosure of this application for all legal purposes.

[0003] Technology proximity

[0004] This document deals with video and image encoding and decoding techniques. Background Art

[0005] Digital video accounts for the largest use of bandwidth on the Internet and other digital communications networks. As the number of connected user devices capable of receiving and displaying video increases, bandwidth demands for digital video usage are expected to continue to grow. Summary of the invention

[0006] The disclosed techniques may be used by video or image decoder or encoder embodiments where reference pictures are used for video encoding or decoding.

[0007] In one example aspect, a method of video processing is disclosed. The method includes, for conversion between a video region of a video and a codec representation of the video region, parsing the codec representation according to a grammar rule defining a relationship between a chroma block size and a color format of the video region, and performing the conversion by performing the parsing according to the grammar rule.

[0008] In another example aspect, another video processing method is disclosed. The method includes determining a codec mode of a codec tree node of a video based on attributes of the video and a chroma format of the video, and using the determined codec mode to perform conversion between a codec representation of the video and a video block of the codec tree node.

[0009] In yet another example aspect, another method of video processing is disclosed. The method includes determining whether a chroma block of a certain size is allowed in a video region of a video based on a rule, and performing conversion between the video region and a codec representation of the video region based on the determination.

[0010] In yet another example aspect, another method of video processing is disclosed. The method includes determining that a codec mode is permitted for a video region based on a rule that allows use of the codec mode for a video condition, and performing conversion between codec representations of pixels in the video region and pixels of the video region based on the determination.

[0011] In yet another example aspect, another method of video processing is disclosed. The method includes using a video codec mode to perform conversion between a video block of a video and a codec representation of the video block, wherein a syntax element signaling the codec mode is selectively included in the codec representation based on a rule.

[0012] In yet another example aspect, another method of video processing is disclosed. The method includes determining that a transform type used during conversion between a chroma block and a codec representation of the chroma block is different from a transform type used for conversion of a corresponding luma block due to the chroma block having a size less than a threshold size, and performing the conversion based on the determination.

[0013] In yet another example aspect, another method of video processing is disclosed. The method includes determining whether to implement a minimum chroma block rule during conversion between a codec representation of a video region and pixel values ​​of the video region based on a codec condition of the video region; and performing conversion based on the determination.

[0014] In yet another example aspect, another method of video processing is disclosed. The method includes, for conversion between a codec representation of a video region in a 4:2:2 format and pixel values ​​of the video region, determining a mode type to be used for conversion based on whether a minimum chroma block rule is enabled for the video region; and performing the conversion based on the determination.

[0015] In yet another example aspect, another method of video processing is disclosed. The method includes, for conversion between a codec representation of a video block and a video block of a video, determining whether block splitting is allowed during conversion based on a mode type used during conversion or a dimension of the video block; and performing the conversion using the determination.

[0016] In yet another example aspect, another method of video processing is disclosed. The method includes, for a codec representation of a video segment of a video and a conversion between video segments, determining to apply a special processing mode to a chroma block of size MxN, where M times N is an integer; and performing the conversion based on the determination.

[0017] In another example aspect, another method of video processing is disclosed. The method includes performing conversion between a video including a video region and a bitstream of the video according to a rule; and wherein the rule specifies a relationship between enabling of a palette mode and a codec type of the video region.

[0018] In another example aspect, another method of video processing is disclosed. The method includes performing conversion between a video including a first video region and a second video region and a bitstream of the video according to a rule; and wherein the rule specifies that when the first block is in intra block copy mode and the second block is in palette mode, a boundary strength (bs) of a deblocking filter of a chroma component of the video is set to 0.

[0019] In another example aspect, another method of video processing is disclosed. The method includes performing conversion between a video and a bitstream of the video according to a format rule, and wherein the format rule specifies that variables related to an input bit depth of the video are constrained according to a profile of the bitstream.

[0020] In another example aspect, another method of video processing is disclosed. The method includes performing conversion between a video and a bitstream of the video according to a format rule, and wherein the format rule specifies that a variable indicating a minimum allowed quantization parameter is constrained according to a profile of the bitstream.

[0021] In yet another example aspect, the above method may be implemented by a video encoder apparatus comprising a processor.

[0022] In yet another example aspect, the above method may be implemented by a video decoder device comprising a processor.

[0023] In yet another example aspect, the methods may be implemented in the form of processor-executable instructions and stored on a computer-readable program medium.

[0024] These and other aspects are described further in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 An example of an intra block copy codec tool is shown.

[0026] Figure 2 An example of a block encoded and decoded in palette mode is shown.

[0027] Figure 3 An example of using palette prediction values ​​to signal palette entries is shown.

[0028] Figure 4 Examples of horizontal and vertical traversal scans are shown.

[0029] Figure 5 An example of encoding and decoding a palette index is shown.

[0030] Figure 6 Examples of 67 intra prediction modes are shown.

[0031] Figure 7Examples of the left and upper neighbors of the current block are shown.

[0032] Figure 8 Examples of ALF filter shapes are shown (chroma: 5×5 diamond, luma: 7×7 diamond).

[0033] Fig. 9 An example of a subsampled Laplacian calculation is shown.

[0034] Fig.10 An example of modified block classification at a virtual boundary is shown.

[0035] Fig.11 is an example illustrating modified ALF filtering for luma components at a virtual boundary.

[0036] Fig.12 Examples of four 1-dimensional 3-pixel patterns of pixel classification in EO are shown.

[0037] Fig.13 Four bands are shown grouped together and represented by their starting band positions.

[0038] Fig.14 The top and left neighboring blocks used in the CIIP weight derivation are shown.

[0039] Fig.15 Luma mapping with a chroma scaling architecture is shown.

[0040] Fig.16 An example of a SCIPU is shown.

[0041] Fig.17A and Fig. 17B A block diagram showing an example of a hardware platform for implementing the techniques described in this document is shown.

[0042] Fig.18 is a flow chart of an example method of video processing.

[0043] Fig.19 An example of the location of spatial merge candidates is shown.

[0044] Fig. 20 An example of candidate pairs considered for redundancy checking of spatial merge candidates is shown.

[0045] Fig.21 is a block diagram illustrating an example video codec system.

[0046] Fig. 22 is a block diagram illustrating an encoder according to some embodiments of the disclosed technology.

[0047] Fig.23is a block diagram illustrating a decoder according to some embodiments of the disclosed technology.

[0048] FIG. 24A to FIG. 24D is a flow chart of an example method of video processing according to some embodiments of the disclosed technology. DETAILED DESCRIPTION

[0049] This document provides various techniques that can be used by a decoder of an image or video bitstream to improve the quality of a decompressed or decoded digital video or image. For brevity, the term "video" is used herein to include both a sequence of pictures (traditionally referred to as video) and individual images. In addition, a video encoder may also implement these techniques during the encoding process in order to reconstruct a decoded frame for further encoding.

[0050] The section titles used in this document are for ease of understanding and do not limit the embodiments and techniques to the corresponding sections. Thus, the embodiments of one section can be combined with the embodiments of other sections.

[0051] 1. Brief Overview

[0052] This document is related to video codec technology. Specifically, it is related to palette codecs using base color based representation in video codecs. It can be applied to existing video codec standards (such as HEVC) or standards to be finalized (Universal Video Codec). It may also be applicable to future video codec standards or video encoders.

[0053] 2. Preliminary Discussion

[0054] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T produced H.261 and H.263, ISO / IEC produced MPEG-1 and MPEG-4 Visual, and the two organizations jointly produced the H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Codec (AVC) and H.265 / HEVC standards. Starting with H.262, video codec standards are based on a hybrid video codec structure that utilizes temporal prediction plus transform codec. In order to explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and introduced them into a reference software called the "Joint Exploration Model" (JEM). In April 2018, the Joint Video Experts Team (JVET) between VCEG (Q6 / 16) and ISO / IEC JTC1SC29 / WG11 (MPEG) was created to work on the VVC standard with the goal of a 50% bitrate reduction compared to HEVC.

[0055] The latest version of the VVC draft, Versatile Video Codec (Draft 4), can be found at:

[0056] http: / / phenix.it-sudparis.eu / jvet / doc_end_user / current_document.php?id=5755

[0057] The latest reference software for VVC, called VTM, can be found at:

[0058] https: / / vcgit.hhi.fraunhofer.de / jvet / VVCSoftware_VTM / tags / VTM-5.0

[0059] 2.1 Intra-frame Block Copy

[0060] Intra-frame block copy (IBC), also known as current picture referencing, has been adopted in HEVC screen content codec extension (HEVC-SCC) and the current VVC test model (through VTM-4.0). IBC extends the concept of motion compensation from inter-frame codecs to intra-frame codecs. Figure 1 As shown, when IBC is applied, the current block is predicted by the reference block in the same picture. Before the current block is encoded or decoded, the samples in the reference block must have been reconstructed. Although IBC is not efficient for most camera-captured sequences, it shows significant encoding and decoding gains for screen content. The reason is that there are many repeated patterns, such as icons and text characters, in the screen content pictures. IBC can effectively remove the redundancy between these repeated patterns. In HEVC-SCC, if the current picture is selected as its reference picture, the inter-frame codec unit (CU) can apply IBC. In this case, MV is renamed as block vector (BV), and BV always has integer pixel precision. In order to be compatible with the main profile HEVC, the current picture is marked as a "long-term" reference picture in the decoded picture buffer (DPB). It should be noted that similarly, in the multi-view / 3D video codec standard, the inter-view reference picture is also marked as a "long-term" reference picture.

[0061] After the BV finds its reference block, a prediction can be generated by copying the reference block. The residual can be obtained by subtracting the reference pixels from the original signal. Then, transforms and quantization can be applied as in other codec modes.

[0062] Figure 1 is a diagram of intra-block copying.

[0063] However, when the reference block is outside the picture, or overlaps with the current block, or is outside the reconstruction area, or is outside the valid area subject to some constraints, some or all pixel values ​​are undefined. Basically, there are two solutions to deal with such problems. One is to prohibit such cases, such as in bitstream consistency. The other is to apply padding to those undefined pixel values. The following subsections describe the solutions in detail.

[0064] 2.2 IBC in HEVC Screen Content Codec Extension

[0065] In the screen content codec extension of HEVC, when a block uses the current picture as a reference, it should be ensured that the entire reference block is within the available reconstruction area, as indicated in the following normative text:

[0066] The variables offsetX and offsetY are derived as follows:

[0067] offsetX=(ChromaArrayType==0)? 0: (mvCLX[0]&0x7?2:0) (8-104)

[0068] offsetY=(ChromaArrayType==0)? 0: (mvCLX[1]&0x7?2:0) (8-105)

[0069] Bitstream conformance requires that when the reference picture is in the current picture, the luma motion vector mvLX shall obey the following constraints:

[0070] – When the derivation process for z-scan order block availability specified in Section 6.4.1 is called with as input (xCurr,yCurr) set to (xCb,yCb), and the adjacent luminance position (xNbY,yNbY) set equal to (xPb+(mvLX[0]>>2)-offsetX,yPb+(mvLX[1]>>2)-offsetY), the output shall be TRUE.

[0071] – When the derivation process for z-scan order block availability specified in section 6.4.1 is called with (xCurr,yCurr) set to (xCb,yCb), and the adjacent luma position (xNbY,yNbY) set equal to (xPb+(mvLX[0]>>2)+nPbW-1+offsetX,yPb+(mvLX[1]>>2)+nPbH-1+offsetY), the output shall be TRUE

[0072] – One or both of the following conditions should be true:

[0073] –The value of (mvLX[0]>>2)+nPbW+xB1+offsetX is less than or equal to 0.

[0074] –The value of (mvLX[1]>>2)+nPbH+yB1+offsetY is less than or equal to 0.

[0075] – The following conditions should be true:

[0076] –(xPb+(mvLX[0]>>2)+nPbSw-1+offsetX) / CtbSizeY-xCurr / CtbSizeY<=yCurr / CtbSizeY-(yPb+(mvLX[1]>>2)+nPbSh-1+offsetY) / CtbSizeY (8-106)

[0077] Therefore, it will not happen that the reference block overlaps with the current block or that the reference block is outside the picture. No padding of the reference or prediction blocks is required.

[0078] 2.3 IBC in the VVC test model

[0079] In the current VVC test model, that is, the VTM-4.0 design, the entire reference block should be together with the current codec tree unit (CTU) and not overlap with the current block. Therefore, there is no need to fill the reference or prediction block. The IBC flag is encoded and decoded as the prediction mode of the current CU. Therefore, for each CU, there are a total of three prediction modes: MODE_INTRA, MODE_INTER, and MODE_IBC.

[0080] 2.3.1 IBC Merge Mode

[0081] In IBC Merge mode, indices pointing to entries in the IBC Merge candidate list are parsed from the bitstream. The construction of the IBC Merge list can be summarized according to the following sequence of steps:

[0082] ●Step 1: Export spatial domain candidates

[0083] ●Step 2: Insert HMVP candidates

[0084] ●Step 3: Insert pairwise average candidates

[0085] In the export of spatial merge candidates, in Fig.19Up to four Merge candidates are selected from the candidates at the positions shown. The export order is A1, B1, B0, A0 and B2. Position B2 is considered only when any PU at position A1, B1, B0, A0 is not available (for example, because it belongs to another slice or piece) or when IBC mode encoding and decoding is not used. After the candidate at position A1 is added, the insertion of the remaining candidates undergoes a redundancy check that ensures that candidates with the same motion information are excluded from the list, thereby improving encoding and decoding efficiency. In order to reduce computational complexity, not all possible candidate pairs are considered in the mentioned redundancy check. Instead, only the possible candidate pairs are considered. Fig. 20 Pairs are linked using arrows in , and a candidate is added to the list only if the corresponding candidate used for redundancy checking does not have the same motion information.

[0086] After inserting the spatial domain candidates, if the IBC Merge list size is still less than the maximum IBC Merge list size, the IBC candidates from the HMVP table can be inserted. A redundancy check is performed when inserting HMVP candidates.

[0087] Finally, the pairwise average candidates are inserted into the IBC Merge list.

[0088] When the reference block identified by a Merge candidate is outside the picture, or overlaps with the current block, or is outside the reconstruction area, or is outside the valid area subject to some constraints, the Merge candidate is called an invalid Merge candidate.

[0089] Note that invalid merge candidates can be inserted into the IBC Merge List.

[0090] 2.3.2 IBC AMVP Model

[0091] In IBC AMVP mode, an AMVP index pointing to an entry in the IBC AMVP list is parsed from the bitstream. The construction of the IBC AMVP list can be summarized according to the following sequence of steps:

[0092] ●Step 1: Export spatial domain candidates

[0093] o Check A0, A1 until a usable candidate is found.

[0094] o Check B0, B1, B2 until a usable candidate is found.

[0095] ●Step 2: Insert HMVP candidates

[0096] ●Step 3: Insert zero candidates

[0097] After inserting the spatial candidates, if the IBC AMVP list size is still less than the maximum IBC AMVP list size, the IBC candidates from the HMVP table may be inserted.

[0098] Finally, the zero candidate is inserted into the IBC AMVP list.

[0099] 2.4 Palette Mode

[0100] The basic idea behind the palette mode is that the samples in a CU are represented by a small set of representative color values. This set is called the palette. And, it is also possible to indicate samples outside the palette by signaling an escape symbol followed by a (possibly quantized) component value. Such samples are called escape samples. Figure 2 shown.

[0101] Figure 2 An example of a block encoded and decoded in palette mode is shown.

[0102] 2.5 Palette Mode in HEVC Screen Content Codec Extension (HEVC-SCC)

[0103] In the palette mode of HEVC-SCC, a prediction method is used to encode and decode the palette and index map.

[0104] 2.5.1 Encoding and decoding of palette entries

[0105] To encode and decode palette entries, palette prediction values ​​are maintained. The maximum size of the palette as well as the palette prediction values ​​are signaled in the SPS. In HEVC-SCC, palette_predictor_initializer_present_flag is introduced in the PPS. When this flag is 1, entries for initializing palette prediction values ​​are signaled in the bitstream. The palette prediction values ​​are initialized at the beginning of each CTU row, each slice, and each slice. Depending on the value of palette_predictor_initializer_present_flag, the palette prediction values ​​are reset to 0 or initialized using the palette prediction value initializer entry signaled in the PPS. In HEVC-SCC, a palette prediction value initializer of size 0 is enabled to allow palette prediction value initialization to be explicitly disabled at the PPS level.

[0106] For each entry in the palette prediction, a reuse flag is signaled to indicate whether it is part of the current palette. Figure 3As shown. The reuse flag is sent using a run-length codec of zero. Thereafter, the number of new palette entries is signaled using an exponential Golomb code of order 0. Finally, the component values ​​of the new palette entries are signaled.

[0107] Figure 3 An example of using palette prediction values ​​to signal palette entries is shown.

[0108] 2.5.2 Palette Index Encoding and Decoding

[0109] like Figure 4 As shown, palette indices are encoded and decoded using horizontal and vertical traversal scans. The scan order is explicitly signaled in the bitstream using palette_transpose_flag. For the rest of the subsection, the scan is assumed to be horizontal.

[0110] Figure 4 Examples of horizontal and vertical traversal scans are shown.

[0111] The palette index is encoded and decoded using two main palette sample modes: "INDEX" and "COPY_ABOVE". As mentioned before, escape symbols are also signaled for "INDEX" mode and are assigned an index equal to the maximum palette size. The mode is signaled using a flag other than top row or when the previous mode was "COPY_ABOVE". In "COPY_ABOVE" mode, the palette index of the sample in the row above is copied. In "INDEX" mode, the palette index is signaled explicitly. For both "INDEX" and "COPY_ABOVE" modes, a run value is signaled, which specifies the number of subsequent samples that are also encoded and decoded using the same mode. When the escape symbol is part of a run in "INDEX" or "COPY_ABOVE" modes, the escape component value is signaled for each escape symbol. The encoding and decoding of the palette index is as follows Figure 5 shown.

[0112] The syntax order is done as follows. First, the number of index values ​​for the CU is signaled. This is followed by signaling the actual index value for the entire CU using truncated binary codec. Both the number of indices and the index values ​​are encoded and decoded in bypass mode. This groups the bypass bins associated with the index together. The palette sample mode (if necessary) and the run length are then signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape samples for the entire CU are grouped together and encoded and decoded in bypass mode.

[0113] An additional syntax element, last_run_type_flag, is signaled after the index value is signaled. This syntax element, combined with the number of indices, eliminates the need to signal the run value corresponding to the last run in the block.

[0114] In HEVC-SCC, palette mode is also enabled for 4:2:2, 4:2:0 and monochrome chroma formats. The signaling of palette entries and palette indices is almost the same for all chroma formats. In the case of non-monochrome formats, each palette entry consists of 3 components. For monochrome formats, each palette entry consists of a single component. For the sub-sampled chroma direction, the chroma samples are associated with luma sample indices that are divisible by 2. After the palette index is reconstructed for the CU, if the sample has only a single component associated with it, only the first component of the palette entry is applied. The only difference in the signaling is the escape component values. For each escape sample, the number of signaled escape component values ​​may be different, depending on the number of components associated with the sample.

[0115] In VVC, a dual-tree codec structure is used to encode and decode based on intra-frame slices, so the luma component and the two chroma components can have different palettes and palette indices. In addition, the two chroma components share the same palette and palette index.

[0116] Figure 5 An example of encoding and decoding a palette index is shown.

[0117] 2.6 Intra-mode encoding and decoding in VVC

[0118] To capture arbitrary edge directions present in natural videos, the number of directional intra modes in VTM5 is extended from 33 used in HEVC to 65. New directional modes not present in HEVC are Figure 6 These denser directional intra prediction modes are applied to all block sizes and for luma and chroma intra prediction.

[0119] In VTM5, for non-square blocks, several normal-angle intra prediction modes are adaptively replaced with wide-angle intra prediction mode.

[0120] In HEVC, each intra-coded block has a square shape and the length of each side is a power of 2. Therefore, no split operation is required to generate intra prediction values ​​using DC mode. In VTM5, blocks can have a rectangular shape, which usually requires a split operation for each block. For DC prediction, in order to avoid the split operation, only the longer side is used to calculate the average for non-square blocks.

[0121] Figure 6Examples of 67 intra prediction modes are shown.

[0122] In order to keep the complexity of the most probable mode (MPM) list generation low, an intra mode codec with 6 MPMs is used by considering two available adjacent intra modes. The following three aspects are considered to construct the MPM list:

[0123] -Default intra mode

[0124] - Neighboring intra mode

[0125] -Export Intra Mode

[0126] Regardless of whether the MRL and ISP codecs are applied, the unified 6-MPM list is used for intra blocks. The MPM list is constructed based on the intra modes of the left neighboring block and the upper neighboring block. Assuming that the mode of the left block is denoted as Left and the mode of the upper block is denoted as Above, the unified MPM list is constructed as follows (the left block and the upper block are as follows Figure 7 shown):

[0127] Figure 7 are examples of left and top neighbors of the current block.

[0128] – When a neighboring block is not available, its intra mode is set to planar by default.

[0129] – If both Left and Above are in non-angle mode:

[0130] ○MPM List → {Plane, DC, V, H, V-4, V+4}

[0131] – If one of “Left” and “Above” is in angle mode and the other is in non-angle mode:

[0132] ○ Set the mode Max as the largest mode among "Left" and "Above"

[0133] ○MPM list → {Plane, Max, DC, Max-1, Max+1, Max-2}

[0134] – If Left and Above are both angles and they are different:

[0135] ○ Set the mode Max as the largest mode among "Left" and "Above"

[0136] ○ If the difference between the patterns "Left" and "Above" is in the range of 2 to 62 (inclusive)

[0137] ■MPM List → {Plane, Left, Above, DC, Max-1, Max+1}

[0138] Otherwise

[0139] ■MPM List → {Plane, Left, Above, DC, Max-2, Max+2}

[0140] – If Left and Above are both angles and they are the same:

[0141] ○MPM list → {Plane, Left, Left-1, Left+1, DC, Left-2}

[0142] In addition, the first binary number of the mpm index codeword is CABAC context coded. A total of three contexts are used, corresponding to whether the current intra block is MRL enabled, ISP enabled, or a normal intra block.

[0143] During the 6 MPM list generation process, pruning is used to remove repeated patterns so that only unique patterns can be included in the MPM lists. For entropy coding and decoding of the 61 non-MPM modes, truncated binary code (TBC) is used.

[0144] For chroma intra mode coding and decoding, a total of 8 intra modes are allowed for chroma intra mode coding and decoding. These modes include 5 traditional intra modes and 3 cross-component linear model modes (CCLM, LM_A and LM_L). The chroma mode signaling and derivation process are shown in Table 2-4. The chroma mode coding and decoding depends directly on the intra prediction mode of the corresponding luminance block. Since separate block partitioning structures for luminance and chrominance components are enabled in the I stripe, one chroma block can correspond to multiple luminance blocks. Therefore, for the chroma DM mode, the intra prediction mode of the corresponding luminance block covering the center position of the current chroma block is directly inherited.

[0145] Table 2-4 Chroma prediction modes derived from luma mode when CCLM is enabled

[0146]

[0147] 2.7 Quantized Residual Block Differential Pulse Codec Modulation (QR-BDPCM)

[0148] In JVET-M0413, a quantized residual block differential pulse codec modulation (QR-BDPCM) is proposed to efficiently encode and decode the screen content.

[0149] The prediction directions used in QR-BDPCM can be vertical and horizontal prediction modes. Intra-frame prediction is performed on the entire block by replicating samples in the prediction direction (horizontal or vertical prediction) similar to intra-frame prediction. The residual is quantized and the delta between the quantized residual and its predicted value (horizontal or vertical) is encoded and decoded. This can be described as follows: For a block of size M (rows) × N (columns), let r ij , 0≤i≤M-1, 0≤j≤N-1 is the prediction residual after performing intra prediction using unfiltered samples from the upper or left block boundary samples horizontally (copying the left neighboring pixel values ​​line by line on the prediction block) or vertically (copying the top neighboring line to each line in the prediction block). Let Q(r i，j ), 0≤i≤M-1, 0≤j≤N-1 represents the residual r i，j The quantized version of , where the residual is the difference between the original block and the predicted block value. Then, block DPCM is applied to the quantized residual samples to obtain a sample with elements The modified M×N array When vertical BDPCM is signaled:

[0150]

[0151] For horizontal prediction, similar rules apply and the residual quantized samples are obtained as follows:

[0152]

[0153] Sample points after residual quantization is sent to the decoder.

[0154] On the decoder side, the above calculation is reversed to produce Q(r i，j ), 0≤i≤M-1, 0≤j≤N-1. For vertical prediction,

[0155]

[0156] For the horizontal case,

[0157]

[0158] The residual Q after inverse quantization -1 (Q(r i，j )) is added to the intra block prediction value to produce the reconstructed sample value.

[0159] The main advantage of this scheme is that inverse DPCM can be done on the fly during coefficient analysis, or one can simply add prediction values ​​when analyzing the coefficients, or perform inverse DPCM after analysis.

[0160] 2.8 Adaptive Loop Filter

[0161] In VTM5, an adaptive loop filter (ALF) with block-based filter adaptation is applied. For the luminance component, one of 25 filters is selected for each 4×4 block based on the direction and activity of the local gradient.

[0162] 2.8.1.1 Filter shape

[0163] In VTM5, two diamond filter shapes are used (such as Figure 8 ). The 7×7 diamond is applied to the luma component, while the 5×5 diamond is applied to the chroma components.

[0164] Figure 8 Examples of ALF filter shapes are shown (chroma: 5×5 diamond, luma: 7×7 diamond)

[0165] 2.8.1.2 Block Classification

[0166] For the luminance component, each 4×4 block is classified into one of 25 classes. The class index C is based on the quantized value of its directionality D and activity. And export as follows:

[0167]

[0168] To calculate D and First, use the one-dimensional Laplace to calculate the gradient in the horizontal, vertical and two diagonal directions:

[0169]

[0170]

[0171]

[0172]

[0173]

[0174] Where the indices i and j refer to the coordinates of the top left sample point within the 4×4 block, and R(i, j) indicates the reconstructed sample point at the coordinate (i, j).

[0175] In order to reduce the complexity of block classification, a sub-sampled one-dimensional Laplace calculation is applied. Fig. 9 As shown, the same subsampling positions are used for gradient calculations in all directions.

[0176] Fig. 9Examples of sub-sampled Laplacian calculations are shown. (a) Sub-sampling positions of vertical gradients (b) Sub-sampling positions of horizontal gradients (c) Sub-sampling positions of diagonal gradients (d) Sub-sampling positions of diagonal gradients.

[0177] Then, the maximum and minimum values ​​of D for the horizontal and vertical gradients are set to:

[0178]

[0179] The maximum and minimum values ​​of the gradients in the two diagonal directions are set to:

[0180]

[0181] To derive the value of the directivity D, these values ​​are compared with each other and two thresholds t1 and t2 are used:

[0182] Step 1. If and are both true, D is set to 0.

[0183] Step 2. If If yes, continue from step 3; otherwise, continue from step 4.

[0184] Step 3. If If yes, D is set to 2; otherwise, D is set to 1.

[0185] Step 3. If If yes, D is set to 4; otherwise, D is set to 3.

[0186] The activity value A is calculated as:

[0187]

[0188] A is further quantized to the range of 0 to 4 (inclusive), and the quantized value is expressed as

[0189] For the chroma components in a picture, no classification method is applied, ie, a single set of ALF coefficients is applied for each chroma component.

[0190] 2.8.1.3 Geometric transformation of filter coefficients and clipping values

[0191] Before filtering each 4×4 luma block, geometric transformations (such as rotations or diagonal and vertical flips) are applied to the filter coefficients f(k, l) and the corresponding filter clipping values ​​c(k, l), depending on the gradient values ​​calculated for the block. This is equivalent to applying these transformations to the points in the filter support region. The idea is to make different blocks with ALF applied more similar by aligning the directionality.

[0192] Three geometric transformations are introduced, including diagonal, vertical flip and rotation:

[0193] Diagonal: f D (k, l) = f(l, k), c D (k, l) = c(l, k) (2-9-9)

[0194] Flip vertically: f V (k, l) = f(k, Kl-1), c V (k, l) = c (k, Kl-1) (2-9-10)

[0195] Rotation: f R (k, l) = f(Kl-1, k), c R (k, l) = c (Kl-1, k) (2-9-11)

[0196] Where K is the size of the filter and 0≤k, l≤K-1 are the coefficient coordinates such that position (0,0) is in the upper left corner and position (K-1,K-1) is in the lower right corner. A transform is applied to the filter coefficients f(k,l) and the clipping value c(k,l) depending on the gradient value calculated for the block. The following table summarizes the relationship between the transform and the four gradients in the four directions.

[0197] Table 2-5 Mapping of gradients and transformations calculated for a block

[0198] Gradient Value Transform <![CDATA[g d2 <g d1 And g h <g v ]]> No transformation <![CDATA[g d2 <g d1 And g v <g h ]]> Diagonal <![CDATA[g d1 <g d2 And g h <g v ]]> Flip Vertically <![CDATA[g d1 <g d2 And g v <g h ]]> Rotation

[0199] 2.8.1.4 Filter parameter signaling

[0200] In VTM5, the ALF filter parameters are signaled in an Adaptive Parameter Set (APS). In one APS, up to 25 sets of luma filter coefficients and clipping value indices and up to one set of chroma filter coefficients and clipping value indices can be signaled. To reduce bit overhead, filter coefficients of different classifications can be merged. In the slice header, the index of the APS for the current slice is signaled.

[0201] The clipping value index decoded from the APS allows the clipping value to be determined using the clipping value luma table and the clipping value chroma table. These clipping values ​​depend on the internal bit depth. More precisely, the clipping value luma table and the clipping value chroma table are obtained by the following formulas:

[0202]

[0203]

[0204] Where B equals the internal bit depth and N equals 4, which is the number of clipping values ​​allowed in VTM5.0.

[0205] The filtering process can be controlled at the CTB level. A flag is always signaled to indicate whether the ALF is applied to the luma CTB. The luma CTB can select a filter set from 16 fixed filter sets and a filter set from the APS. The filter set index for the luma CTB is signaled to indicate which filter set is applied. The 16 fixed filter sets are predefined and hard-coded in both the encoder and decoder.

[0206] The filter coefficients are quantized with a norm equal to 128. To limit the multiplication complexity, bitstream consistency is applied so that coefficient values ​​in non-central positions should be within -2 7 to 2 7 The center position coefficient is not signaled in the bitstream and is assumed to be equal to 128.

[0207] 2.8.1.5 Filtering process

[0208] At the decoder side, when ALF is enabled for CTB, each sample point R(i, j) in the CU is filtered to obtain the sample value R′(i, j), as shown below,

[0209] R′(i, j)=R(i, j)+((∑ k≠0 ∑ l≠0 f(k,l)×K(R(i+k,j+l)-R(i,j),c(k,l))+64)>>7) (2-9-14)

[0210] Where f(k, l) represents the decoded filter coefficients, K(x, y) is the clipping function, and c(k, l) represents the decoded clipping parameters. The variables k and l are in and where L represents the filter length. The clipping function K(x, y) = min(y, max(-y, x)) corresponds to the function Clip3(-y, y, x).

[0211] 2.8.1.6 Reducing the Virtual Boundary Filtering Process of Line Buffers

[0212] In VTM5, in order to reduce the line buffer requirements of ALF, modified block classification and filtering is adopted for samples near horizontal CTU boundaries. To this end, a virtual boundary is defined as a line by shifting the horizontal CTU boundary with "N" samples, such as Fig.10 As shown, where N is equal to 4 for the luminance component and N is equal to 2 for the chrominance component.

[0213] Fig.10 An example of modified block classification at a virtual boundary is shown.

[0214] like Fig.11 As shown, a modified block classification is applied to the luminance component, and the activity value A is scaled accordingly by taking into account the reduced number of samples used in the one-dimensional Laplace gradient calculation.

[0215] For the filtering process, symmetric padding operations at virtual boundaries are used for both luma and chroma components. Fig.11 As shown in FIG. 1 , when the filtered sample point is below the virtual boundary, the adjacent sample points above the virtual boundary are filled in. At the same time, the corresponding sample points on the other side are also filled in symmetrically.

[0216] Fig.11 An example of modified ALF filtering for luma components at a virtual boundary is shown.

[0217] 2.9 Sample Adaptive Offset (SAO)

[0218] The encoder applies sample adaptive offset (SAO) to the reconstructed signal after the deblocking filter by using the offset specified for each CTB. The HM encoder first decides whether to apply the SAO process to the current strip. If SAO is applied to the strip, each CTB is classified into one of the five SAO types shown in Table 2-6. The concept of SAO is to classify pixels into categories and reduce distortion by adding offsets to pixels of each category. The SAO operation includes an edge offset (EdgeOffset, EO) and a band offset (Band Offset, BO), the edge offset (EO) uses edge attributes for pixel classification in SAO types 1-4, and the band offset (BO) uses pixel intensity for pixel classification in SAO type 5. Each applicable CTB has SAO parameters, including sao_merge_left_flag, sao_merge_up_flag, SAO type, and four offsets. If sao_merge_left_flag is equal to 1, the current CTB will reuse the SAO type and the offset to the left of the CTB. If sao_merge_up_flag is equal to 1, the current CTB will reuse the SAO type and CTB upward offset.

[0219] Table 2-6 SAO type specifications

[0220] SAO Type The type of sample adaptive offset to use Category No. 0 none 0 1 1D 0 degree pattern edge offset 4 2 1D 90 degree pattern edge offset 4 3 1D 135 degree pattern edge offset 4 4 1D 45 degree pattern edge offset 4 5 With offset 4

[0221] 2.9.1 Operations of each SAO type

[0222] Edge offset uses four 1-dimensional 3-pixel patterns to classify the current pixel p by considering the edge orientation information, such as Fig.12 From left to right, they are: 0 degrees, 90 degrees, 135 degrees, and 45 degrees.

[0223] Fig.12 Examples of four 1-dimensional 3-pixel patterns of pixel classification in EO are shown.

[0224] Each CTB is classified into one of five categories according to Tables 2–7.

[0225] Table 2-7 EO pixel classification rules

[0226] category condition meaning 0 None of the following Mostly monotonous 1 p<2 neighborhood Local Minimum 2 p<1 neighborhood &&p==1 neighborhood edge 3 p>1neighborhood&&p==1neighborhood edge 4 p>2 neighborhood Local maximum

[0227] Band offset (BO) classifies all pixels in a CTB region into 32 uniform bands by using the five most significant bits of the pixel value as the band index. In other words, the pixel intensity range is split into 32 equal segments from zero to the maximum intensity value (e.g., 255 for 8-bit pixels). Four adjacent bands are grouped together, and each group is indicated by its leftmost position, as shown in Figure 1. Fig.13 The encoder searches all positions to obtain the group with the greatest distortion reduction by compensating for the offset of each band.

[0228] Fig.13 An example is shown where four bands are grouped together and represented by their starting band positions.

[0229] 2.10 Combined Inter and Intra Prediction (CIIP)

[0230] In VTM5, when encoding and decoding a CU in Merge mode, if the CU contains at least 64 luma samples (i.e., the CU width multiplied by the CU height is equal to or greater than 64), and if both the CU width and the CU height are less than 128 luma samples, an additional flag is signaled to indicate whether the combined inter / intra prediction (CIIP) mode is applied to the current CU. As the name implies, CIIP prediction combines the inter prediction signal with the intra prediction signal. The inter prediction signal P in CIIP mode inter is derived using the same inter-frame prediction process as applied to the conventional Merge mode; and the intra-frame prediction signal P intra is derived after the conventional intra prediction process with planar mode. The intra and inter prediction signals are then combined using a weighted average, where the weights of the top and left neighboring blocks (e.g. Fig.14 The weight value is calculated based on the encoding and decoding mode shown in the figure, as follows:

[0231] - If top neighboring is available and is intra-coded, set isIntraTop to 1, otherwise set isIntraTop to 0;

[0232] - If the left neighbor is available and is intra-coded, set isIntraLeft to 1, otherwise set isIntraLeft to 0;

[0233] - If (isIntraLeft + isIntraLeft) is equal to 2, then set wt to 3;

[0234] - Otherwise, if (isIntraLeft + isIntraLeft) is equal to 1, set wt to 2;

[0235] - Otherwise, set wt to 1.

[0236] The CIIP forecast is formed as follows:

[0237] P CIIP =((4-wt)*P inter +wt*P intra +2)>>2 (3-2)

[0238] Fig.14 Examples of top and left neighboring blocks used in CIIP weight derivation are shown.

[0239] 2.11 Luminance Mapping and Chroma Scaling (LMCS)

[0240] In VTM5, a codec tool called Luma Mapping and Chroma Scaling (LMCS) is added as a new processing block before the loop filter. LMCS has two main components: 1) loop mapping of the luma component based on an adaptive piecewise linear model; 2) for the chroma components, a chroma residual scaling that depends on luma is applied. Fig.15 The LMCS architecture is shown from the decoder's perspective. Fig.15 The dashed blocks in indicate where in the mapped domain the processing is applied, and these include inverse quantization, inverse transform, luma intra prediction, and adding the luma prediction to the luma residual. Fig.15 Unshaded blocks in the are indicate where processing is applied in the original (i.e., non-mapped) domain; and these include loop filters such as deblocking, ALF and SAO, motion compensated prediction, chroma intra prediction, adding the chroma prediction to the chroma residual, and storing the decoded picture as a reference picture. Fig.15 The checkered blocks in show the new LMCS functional blocks, including the forward mapping and inverse mapping of the luma signal and the chroma scaling process that depends on luma. Like most other tools in VVC, LMCS can be enabled / disabled at the sequence level using the SPS flag.

[0241] Fig.15 An example of a luma mapping and chroma scaling architecture is shown.

[0242] 2.12 Dual Tree Partition

[0243] In the current VVC design, for I slices, each CTU can be divided into codec units with 64x64 luma samples using implicit quadtree partitioning, and these codec units are the roots of two separate coding_tree syntax structures for luma and chroma.

[0244] Since the dual tree in the intra picture allows different partitioning to be applied in the chroma codec tree compared to the luma codec tree, the dual tree introduces a longer codec pipeline, and the QTBT MinQTSizeC value range in the chroma tree and MinBtSizeY and MinTTSizeY allow smaller chroma blocks, such as 2x2, 4x2, and 2x4. This brings difficulties to the practical decoder design. In addition, several prediction modes (such as CCLM, planar and angular modes) require multiplication. In order to alleviate the above problems, small chroma block sizes (2×2 / 2×4 / 4×2) are restricted in the dual tree as partition restrictions.

[0245] 2.13 Minimum Chroma Intra Prediction Unit (SCIPU) in JVET-O0050

[0246] Small chroma sizes are not friendly to hardware implementations. In the case of dual trees, chroma blocks with too small sizes are prohibited. However, in the case of a single tree, VVC Draft 5 still allows 2x2, 2x4, and 4x2 chroma blocks. In order to limit the size of the chroma block, in a single codec tree, SCIPU is defined in JVET-O0050 as a codec tree node whose chroma block size is greater than or equal to TH chroma samples and has at least one sub-luminance block less than 4TH luminance samples, where TH is set to 16 in this draft. It is required that in each SCIPU, all CBs are inter-frame, or all CBs are non-inter-frame, i.e., intra-frame or IBC. In the case of non-inter-frame SCIPU, it is further required that the chroma of the non-inter-frame SCIPU should not be further divided and the luminance of the SCIPU is allowed to be further divided. In this way, the minimum chroma intra-frame CB size is 16 chroma samples, and 2x2, 2x4, and 4x2 chroma CBs are removed. Additionally, in case of non-inter SCIPU, chroma scaling is not applied.

[0247] Fig.16 Two SCIPU examples are shown. Fig.16 In (a), a chroma CB with 8x4 chroma samples and three luma CBs (4x8, 8x8, 4x8 luma CB) form a SCIPU, because the ternary tree (TT) partitioned from the 8x4 chroma samples will result in a chroma CB with less than 16 chroma samples. Fig.16In (b), a chroma CB of 4x4 chroma samples (on the left of 8x4 chroma samples) and three luma CBs (8x4, 4x4, 4x4 luma CB) form one SCIPU, and another chroma CB of 4x4 samples (on the right of 8x4 chroma samples) and two luma CBs (8x4, 8x4 luma CB) form one SCIPU, because the binary tree (BT) partitioned from the 4x4 chroma samples will result in a chroma CB of less than 16 chroma samples.

[0248] Fig.16 A SCIPU example is shown.

[0249] If the current slice is an I slice or the current SCIPU has a 4x4 luma split after being further divided once, the type of the SCIPU is inferred to be non-inter (because inter 4x4 is prohibited in VVC); otherwise, the type of the SCIPU (inter or non-inter) is indicated by a signaled flag before parsing the CU in the SCIPU.

[0250] 2.14 Small Chroma Block Constraints in VVC Draft 6

[0251] In VVC Draft 6 (JVET-O2001-vE.docx), the constraints on small chroma blocks are implemented as follows (the relevant parts are marked in bold italics).

[0252]

[0253]

[0254]

[0255] 2.14.1.1 Codec Unit Syntax

[0256]

[0257]

[0258]

[0259]

[0260] The inputs to this process are:

[0261] – Codec block size cbSize in luma samples,

[0262] – Multiple types of tree depth mttDepth,

[0263] – the variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the CTU, and when using a dual tree, whether the luma (DUAL_TREE_LUMA) or chroma components (DUAL_TREE_CHROMA) are currently being processed,

[0264]

[0265] The output of this process is the variable allowSplitQt.

[0266] The variable allowSplitQt is exported as follows:

[0267] – Set allowSplitQt equal to false if one or more of the following conditions are true:

[0268] –treeType is equal to SINGLE_TREE or DUAL_TREE_LUMA, and cbSize is less than or equal to MinQtSizeY

[0269] –treeType is equal to DUAL_TREE_CHROMA, and cbSize / SubWidthC is less than or equal to MinQtSizeC

[0270] –mttDepth is not equal to 0

[0271] –treeType is equal to DUAL_TREE_CHROMA, and (cbSize / SubWidthC) is less than or equal to 4

[0272]

[0273] – Otherwise, set allowSplitQt equal to true.

[0274]

[0275] The inputs to this process are:

[0276] – Binary split mode btSplit,

[0277] – Codec block width cbWidth in luma samples,

[0278] – Codec block height cbHeight in luma samples,

[0279] – the position (x0, y0) of the top-left luma sample of the considered codec block relative to the top-left luma sample of the picture,

[0280] – Multiple types of tree depth mttDepth,

[0281] – Maximum multi-type tree depth maxMttDepth with offset,

[0282] – Maximum binary tree size maxBtSize,

[0283] – minimum quadtree size minQtSize,

[0284] – Split index partIdx,

[0285] – the variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the CTU, and when using a dual tree, whether the luma (DUAL_TREE_LUMA) or chroma components (DUAL_TREE_CHROMA) are currently being processed,

[0286]

[0287] The output of this process is the variable allowBtSplit.

[0288] Table 6-2 Specifications of parallelTtSplit and cbSize based on btSplit

[0289]

[0290] The variables parallelTtSplit and cbSize are exported as specified in Table 6–2.

[0291] The variable allowBtSplit is exported as follows:

[0292] – Set allowBtSplit equal to false if one or more of the following conditions are true:

[0293] –cbSize is less than or equal to MinBtSizeY

[0294] –cbWidth is greater than maxBtSize

[0295] –cbHeight is greater than maxBtSize

[0296] –mttDepth is greater than or equal to maxMttDepth

[0297] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0298]

[0299] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0300] –btSplit is equal to SPLIT_BT_VER

[0301] –y0+cbHeight is greater than pic_height_in_luma_samples

[0302] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0303] –btSplit is equal to SPLIT_BT_VER

[0304] –cbHeight is greater than MaxTbSizeY

[0305] –x0+cbWidth is greater than pic_width_in_luma_samples

[0306] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0307] –btSplit is equal to SPLIT_BT_HOR

[0308] –cbWidth is greater than MaxTbSizeY

[0309] –y0+cbHeight is greater than pic_height_in_luma_samples

[0310] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0311] –x0+cbWidth is greater than pic_width_in_luma_samples

[0312] –y0+cbHeight is greater than pic_height_in_luma_samples

[0313] –cbWidth is greater than minQtSize

[0314] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0315] –btSplit is equal to SPLIT_BT_HOR

[0316] –x0+cbWidth is greater than pic_width_in_luma_samples

[0317] –y0+cbHeight is less than or equal to pic_height_in_luma_samples

[0318] – Otherwise, if all of the following are true, then set allowBtSplit equal to false:

[0319] –mttDepth is greater than 0

[0320] –partIdx is equal to 1

[0321] -MttSplitMode[x0][y0][mttDepth-1] equals parallelTtSplit

[0322] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0323] –btSplit is equal to SPLIT_BT_VER

[0324] –cbWidth is less than or equal to MaxTbSizeY

[0325] –cbHeight is greater than MaxTbSizeY

[0326] – Otherwise, if all of the following are true, then set allowBtSplit equal to false

[0327] –btSplit is equal to SPLIT_BT_HOR

[0328] –cbWidth is greater than MaxTbSizeY

[0329] –cbHeight is less than or equal to MaxTbSizeY

[0330] – Otherwise, set allowBtSplit equal to true.

[0331]

[0332] The inputs to this process are:

[0333] – Ternary division mode ttSplit,

[0334] – Codec block width cbWidth in luma samples,

[0335] – Codec block height cbHeight in luma samples,

[0336] – the position (x0, y0) of the top-left luma sample of the considered codec block relative to the top-left luma sample of the picture,

[0337] – Multiple types of tree depth mttDepth

[0338] – Maximum multi-type tree depth maxMttDepth with offset,

[0339] – Maximum ternary tree size maxTtSize,

[0340] – the variable treeType, which specifies whether a single tree (SINGLE_TREE) or a dual tree is used to partition the CTU, and when using a dual tree, whether the luma (DUAL_TREE_LUMA) or chroma components (DUAL_TREE_CHROMA) are currently being processed,

[0341]

[0342] The output of this process is the variable allowTtSplit.

[0343] Table 6-3 Specification of cbSize based on ttSplit

[0344]

[0345] The variable cbSize is exported as specified in Table 6–3.

[0346] The variable allowTtSplit is exported as follows:

[0347] – Set allowTtSplit equal to false if one or more of the following conditions are true:

[0348] –cbSize is less than or equal to 2*MinTtSizeY

[0349] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0350] –cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0351] –mttDepth is greater than or equal to maxMttDepth

[0352] –x0+cbWidth is greater than pic_width_in_luma_samples

[0353] –y0+cbHeight is greater than pic_height_in_luma_samples

[0354] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0355]

[0356] – Otherwise, set allowTtSplit equal to true.

[0357] pred_mode_flag is equal to 1 and specifies that the current codec unit is coded in the intra prediction mode.

[0358] When pred_mode_flag is not present, the inference is as follows:

[0359] - If cbWidth is equal to 4 and cbHeight is equal to 4, pred_mode_flag is inferred to be equal to 1.

[0360]

[0361] – Otherwise, pred_mode_flag is inferred to be equal to 1 when decoding I slices and to be equal to 0 when decoding P or B slices, respectively.

[0362] For x=x0..x0+cbWidth-1 and y=y0..y0+cbHeight-1, the variable CuPredMode[chType][x][y] is derived as follows:

[0363] – If pred_mode_flag is equal to 0, set CuPredMode[chType][x][y] equal to MODE_INTER.

[0364] – Otherwise (pred_mode_flag is equal to 1), set CuPredMode[chType][x][y] equal to MODE_INTRA.

[0365] pred_mode_ibc_flag is equal to 1 to specify that the current codec unit is coded in IBC prediction mode. pred_mode_ibc_flag is equal to 0 to specify that the current codec unit is not coded in IBC prediction mode.

[0366] When pred_mode_ibc_flag is not present, the inference is as follows:

[0367] – If cu_skip_flag[x0][y0] is equal to 1, and cbWidth is equal to 4, and cbHeight is equal to 4, then pred_mode_ibc_flag is inferred to be equal to 1.

[0368] – Otherwise, if cbWidth and cbHeight are both equal to 128, pred_mode_ibc_flag is inferred to be equal to 0.

[0369]

[0370] – Otherwise, pred_mode_ibc_flag is inferred to be equal to the value of sps_ibc_enabled_flag when decoding I slices and to be equal to 0 when decoding P or B slices, respectively.

[0371] When pred_mode_ibc_flag is equal to 1, for x=x0..x0+cbWidth−1 and y=y0..y0+cbHeight−1, the variable CuPredMode[chType][x][y] is set equal to MODE_IBC.

[0372] 3. Question

[0373] 1. Currently, IBC is treated as MODE_TYPE_INTRA and therefore small chroma blocks are prohibited, which leads to unnecessary loss of codec efficiency.

[0374] 2. Currently, the palette is treated as MODE_TYPE_INTRA, and therefore small chroma blocks are prohibited, which leads to unnecessary loss of codec efficiency.

[0375] 3. Currently, the small chroma block constraint does not take into account the color subsampling format.

[0376] 4. Currently, the same partitioning and prediction mode constraints for tiles are applied to all chroma formats. However, it may be desirable to design different constraint mechanisms for tiles in 4:2:0 and 4:2:2 chroma formats.

[0377] 5. Currently, palette mode flag signaling depends on modeType, which is undesirable because the palette may not apply small block constraints.

[0378] 6. Currently, when cu_skip_flag is equal to 1 but MODE_TYPE is equal to MODE_TYPE_INTRA, for P / B slices, the IBC mode flag is inferred to be 0, which is not legal in syntax parsing.

[0379] 7. Currently, non-4x4 luma IBC modes are not allowed for SCIPU luma blocks, which may be undesirable and may result in codec efficiency loss.

[0380] 8. 2x H chroma blocks are still allowed, which is not friendly to hardware implementations.

[0381] 9. Although CIIP uses intra prediction, CIIP is treated as MODE_INTER, which breaks the constraint in some cases.

[0382] 10. When SCIPU is applied, the incremental QP of chroma can be signaled depending on the luma split. For example, when the current block dimension in the luma sample is 16×8 and vertical TT splitting is used, a local dual tree can be applied. Specify qgOnC=qgOnC&&(cbSubdiv+2<=cu_chroma_qp_offset_subdiv), so if cbSubdiv+2<=cu_chroma_qp_offset_subdiv, qgOnC is set to zero. This conditional setting assumes that the chroma components are also divided by TT. In the case of a local dual tree, the chroma components may not be divided, so cbSubdiv may be greater than cu_chroma_qp_offset_subdiv. IsCuChromaQpOffsetCoded should be set to 0 to allow signaling of the QP of chroma. However, because qgOnC is set to 0, IsCuChromaQpOffsetCoded is not set to 0.

[0383] 11. The maximum transform size for lossless codecs can be set differently from the maximum transform size for lossy codecs.

[0384] 4. Examples of technical solutions and embodiments

[0385] The following list should be considered as examples. These techniques should not be interpreted narrowly. In addition, these techniques can be combined in any way.

[0386] In this document, an "MxN codec tree node" indicates an M×N block, where M is the block width and N is the block height in luma samples, which may be further partitioned, such as by QT / BT / TT. For example, a block may be a QT node or a BT node or a TT node. A codec tree node may be a codec unit (e.g., with three color components for a single tree, two chroma color components for a dual-tree chroma codec, and only a luma color component for a dual-tree luma codec), or a luma codec block, or a chroma codec block. A "small codec tree node unit" may indicate a codec tree node with a block size MxN equal to 32 / 64 / 128 in luma samples.

[0387] If not mentioned otherwise, the width W and height H of a codec block are measured in luma samples. For example, an MxN codec block refers to an MxN luma block, and / or two (M / SubWidthC)x(N / SubHeightC) chroma blocks, where SubWidthC and SubHeightC are derived from the chroma format as follows.

[0388]

[0389]

[0390] 1. Whether and / or how to split into small blocks may depend on the color format.

[0391] a. In one example, for a 4:4:4 color format, constraints on chroma block sizes may follow those on luma blocks.

[0392] b. In one example, for a 4:2:2 color format, constraints on chroma block size may follow those for a 4:2:0 color format.

[0393] c. In one example, for 4:0:0 and / or 4:4:4 chroma formats, constraints on tile partitioning and / or prediction modes may not apply.

[0394] d. In one example, constraints on tile partitioning and / or prediction modes may be applied differently for different chroma formats.

[0395] i. In one example, for an MxN (such as 8x8) codec tree node with horizontal BT split, in a 4:2:2 chroma format, horizontal BT split may be allowed for both chroma blocks and luma blocks, while in a 4:2:0 chroma format, horizontal BT split may be allowed for luma blocks but disabled for chroma blocks.

[0396] ii. In one example, for an MxN (such as 16x4) codec tree node with vertical BT split, in a 4:2:2 chroma format, vertical BT split may be allowed for both chroma blocks and luma blocks, whereas in a 4:2:0 chroma format, vertical BT split may be allowed for luma blocks but disabled for chroma blocks.

[0397] iii. In one example, for an MxN (such as 8x16) codec tree node with horizontal TT split, in a 4:2:2 chroma format, horizontal TT split may be allowed for both chroma and luma blocks, whereas in a 4:2:0 chroma format, horizontal TT split may be allowed for luma blocks but disabled for chroma blocks.

[0398] iv. In one example, for an MxN (such as 32x4) codec tree node with vertical TT split, in a 4:2:2 chroma format, vertical TT split may be allowed for both chroma and luma blocks, whereas in a 4:2:0 chroma format, vertical TT split may be allowed for luma blocks but disabled for chroma blocks.

[0399] v. In one example, for 4:0:0 and / or 4:4:4 color formats, the tile constraint may not apply.

[0400] e. In one example, whether SCIPU is enabled depends on the color format.

[0401] i. In one example, for 4:2:0 and 4:2:2 color formats, SCIPU is enabled.

[0402] ii. In one example, for 4:0:0 and / or 4:4:4 color formats, the SCIPU is disabled.

[0403] 1. In one example, for 4:0:0 and / or 4:4:4 color formats, modeType may always be equal to MODE_TYPE_ALL.

[0404] 2. In one example, for 4:0:0 and / or 4:4:4 color formats, modeTypeCondition may always be equal to 0.

[0405] 2. How to determine the prediction mode (and / or modeType) for a (sub)block of a codec tree node may depend on the chroma format.

[0406] a. In one example, if one of the following conditions is true, for 4:2:2 chroma format, the modeType of the (sub)blocks partitioned by this codec tree node can be equal to MODE_TYPE_ALL, while for 4:2:0 chroma format, modeType can be equal to MODE_TYPE_INTRA or MODE_TYPE_INTER.

[0407] i. MxN (such as 8x8) codec tree node with horizontal BT partition

[0408] ii. MxN (such as 16x4) codec tree node with vertical BT partition

[0409] iii. MxN (such as 8x16) codec tree node with horizontal TT partition

[0410] iv. MxN (such as 32x4) codec tree node with vertical TT partition

[0411] 3. Propose to rename MODE_TYPE_INTRA to MODE_TYPE_NO_INTER and restrict the use of MODE_INTER.

[0412] a. In one example, when the modeType of the codec unit is equal to MODE_TYPE_NO_INTER, MODE_INTER may be disabled.

[0413] 4. Propose to rename MODE_TYPE_INTER to MODE_TYPE_NO_INTRA and restrict the use of MODE_INTRA.

[0414] a. In one example, when the modeType of the codec unit is equal to MODE_TYPE_NO_INTRA, MODE_INTRA may be disabled.

[0415] 5. The mode constraint flag may never be signaled in 4:2:2 and / or 4:0:0 and / or 4:4:4 chroma formats.

[0416] a. In one example, when the mode constraint flag is not present, it can be inferred to be equal to 1.

[0417] i. Alternatively, when the mode constraint flag is not present, it can be inferred to be equal to 0.

[0418] 6. Whether and / or how to apply SCIPU on an MxN codec block with block width M and block height N may depend on whether the color format is 4:2:0 or 4:2:2.

[0419] a. In one example, in a 4:2:2 color format, for an MxN codec block with a block width of M and a block height of N, the SCIPU can be enabled only if M times N (expressed as M*N) equals 64 or 32.

[0420] b. In one example, a codec tree node with M*N=128 may never be considered as a SCIPU block in 4:2:2 color format.

[0421] c. In one example, a codec tree node with BT partition and M*N=64 may never be considered as a SCIPU block in 4:2:2 color format.

[0422] d. In one example, a codec tree node with split_qt_flag equal to 1 and M*N=64 may be a SCIPU block in 4:2:2 color format.

[0423] e. In one example, a codec tree node with TT partition and M*N=64 can be considered as a SCIPU block in 4:2:2 color format.

[0424] f. In one example, a codec tree node with BT partition and M*N=32 can be considered as a SCIPU block in 4:2:2 color format.

[0425] g. In the above description, for the SCIPU block in 4:2:2 color format, modeTypeCondition may always be equal to 1.

[0426] h. In the above description, for a SCIPU block in 4:2:2 color format, the current block in the parent node and all sub-blocks under the child leaf node can only allow MODE_TYPE_INTRA.

[0427] 7. In 4:2:2 color format, the modeTypeCondition of the SCIPU block can always be equal to 1.

[0428] a. In one example, for a 4:2:2 color format, modeTypeCondition can be equal to 0 or 1.

[0429] b. In one example, for a SCIPU block in 4:2:2 color format, modeTypeCondition may never be equal to 2.

[0430] 8. In 4:2:2 color format, the modeType of the SCIPU block can always be equal to MODE_TYPE_INTRA.

[0431] a. In one example, in 4:2:2 color format, modeType can be equal to MODE_TYPE_ALL or MODE_TYPE_INTRA.

[0432] b. In one example, for a SCIPU block in 4:2:2 color format, MODE_TYPE_INTER may be disabled.

[0433] 9. Whether block splitting is allowed may depend on modeType and / or block size.

[0434] a. In one example, whether BT and / or TT partitioning is allowed for a block may depend on modeType.

[0435] i. In one example, if modeType is equal to MODE_TYPE_INTER, BT splitting may be disabled for the current codec block (eg, allowBtSplit is set equal to false).

[0436] ii. In one example, if modeType is equal to MODE_TYPE_INTER, TT splitting may be disabled for the current codec block (eg, allowTtSplit is set equal to false).

[0437] b. In one example, whether BT and / or TT partitioning is allowed for a block may depend on the modeType and the block size.

[0438] i. In one example, for an MxN codec block with a block width of M and a block height of N, when M*N is less than or equal to 32 and modeType is equal to MODE_TYPE_INTER, BT splitting may be prohibited (eg, allowBtSplit is set to false).

[0439] ii. In one example, for an MxN codec block with a block width of M and a block height of N, when M*N is less than or equal to 64 and modeType is equal to MODE_TYPE_INTER, TT splitting may be prohibited (eg, allowTtSplit is set to false).

[0440] 10. When the modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER, the division of the codec tree may be restricted

[0441] a. In one example, when modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER, BT partitioning may be prohibited.

[0442] b. In one example, when modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER, TT partitioning may be prohibited.

[0443] c. In one example, when modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER, QT splitting may be disabled.

[0444] d. In one example, when the modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER and the luma block size is less than or equal to 32, BT splitting may be disabled.

[0445] e. In one example, when modeTypeCurr of the codec tree is equal to MODE_TYPE_INTER and the luma block size is less than or equal to 64, TT splitting may be prohibited.

[0446] 11. The codec unit with treeType DUAL_TREE_LUMA can be encoded and decoded in inter-frame mode.

[0447] a. In one example, even for a color format having multiple color components, a codec unit encoded in an inter-frame coding mode (ie, MODE_INTER) may include only a luma component.

[0448] b. In one example, pred_mode_flag may need to be parsed for DUAL_TREE_LUMA chunks.

[0449] c. In one example, for DUAL_TREE_LUMA blocks coded in inter mode, the same constraints for inter mode of SINGLE_TREE can also be applied.

[0450] i. In one example, 4x4 DUAL_TREE_LUMA inter blocks may be disabled.

[0451] 12. Chroma Intra (and / or IBC) blocks with a block width equal to M (such as M=2) chroma samples may not be allowed.

[0452] a. In one example, 2xN (such as N≤64) chroma intra blocks may not be allowed in a dual tree.

[0453] i. In one example, when treeType is equal to DUAL_TREE_CHROMA and block width is equal to 4 chroma samples, vertical BT splitting can be disabled.

[0454] ii. In one example, when treeType is equal to DUAL_TREE_CHROMA and block width is equal to 8 chroma samples, vertical TT splitting may be disabled.

[0455] b. In one example, 2xN (such as N<=64) chroma intra (and / or IBC) blocks may not be allowed in a single tree.

[0456] i. In one example, for an M×N (such as M=8 and N<=64) codec tree node with vertical BT partition, one of the following processes may be applied.

[0457] 1. For 4xN or 4x(N / 2) chroma blocks, vertical BT splitting may be prohibited, but for 8xN luma blocks, vertical BT splitting may be allowed.

[0458] 2.4xN or 4x(N / 2) chroma block may not be vertically BT-partitioned, and it may be coded or decoded by MODE_INTRA or MODE_IBC.

[0459] 3. Vertical BT partitioning may be allowed for both 8xN luma blocks and 4xN or 4x(N / 2) chroma blocks, but both luma blocks and chroma blocks are not coded in MODE_INTRA (eg, may be coded in MODE_INTER or MODE_IBC).

[0460] ii. In one example, for an M×N (such as M=16 and N<=64) codec tree node with vertical TT partition, one of the following processes may be applied.

[0461] 1. For 8xN or 8x(N / 2) chroma blocks, vertical TT partitioning may be prohibited, but for 16xN luma blocks, vertical TT partitioning may be allowed.

[0462] 2.8xN or 8×(N / 2) chroma blocks may not be vertically TT-partitioned and may be coded or decoded in MODE_INTRA or MODE_IBC.

[0463] 3. Vertical TT partitioning may be allowed for both 16xN luma blocks and 8xN or 8x(N / 2) chroma blocks, but both luma blocks and chroma blocks may not be coded in MODE_INTRA (eg, may be coded in MODE_INTER or MODE_IBC).

[0464] 13. IBC mode may be allowed for luma blocks and / or chroma blocks regardless of whether the luma blocks and / or chroma blocks are of small block size.

[0465] a. In one example, for luma blocks - including 8x4 / 8x8 / 16x4 and 4xN (such as N<=64) luma blocks - IBC mode may be allowed even if modeType is equal to MODE_TYPE_INTRA.

[0466] b. In one example, IBC mode may be allowed for chroma blocks even if modeType is equal to MODE_TYPE_INTRA.

[0467] 14. Signaling of the IBC prediction mode flag may depend on the prediction mode type (eg, MODE_TYPE_INTRA).

[0468] a. In one example, when treeType is not equal to DUAL_TREE_CHROMA and modeType is equal to MODE_TYPE_INTRA, the IBC prediction mode flag for non-SKIP blocks (eg, codec blocks not coded in skip mode) may be explicitly signaled in the bitstream.

[0469] 15. The IBC prediction mode flag may be inferred depending on the CU SKIP flag and the mode type (eg, modeType).

[0470] a. In one example, if the current block is encoded in skip mode (such as cu_skip_flag equal to 1), and modeType equals MODE_TYPE_INTRA, then the IBC prediction mode flag (such as pred_mode_ibc_flag) can be inferred to be equal to 1.

[0471] 16. Explicit signaling of palette mode flags may not depend on modeType.

[0472] a. In one example, regardless of modeType, palette mode flag (such as pred_mode_plt_flag) signaling may depend on slice type, block size, prediction mode, etc.

[0473] b. In one example, when modeType is equal to MODE_TYPE_INTER or MODE_TYPE_INTRA, the palette mode flag (such as pred_mode_plt_flag) is inferred to be 0.

[0474] 17. When modeType is equal to MODE_TYPE_INTER, IBC mode can be used

[0475] a. In one example, when modeType is equal to MODE_TYPE_INTRA, chroma IBC may be disabled.

[0476] b. In one example, when modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER, IBC mode may be allowed to be used.

[0477] c. In one example, IBC mode may be allowed regardless of modeType.

[0478] d. In one example, within one SCIPU, both IBC and inter-frame modes may be allowed.

[0479] e. In one example, the size of an IBC chroma block may always correspond to the size of the corresponding luma block.

[0480] f. In one example, when modeType is equal to MODE_TYPE_INTER and the codec unit size in luma is 4x4, the signaling of pred_mode_ibc_flag can be skipped and pred_mode_ibc_flag can be inferred to be equal to 1.

[0481] 18. When modeType is MODE_TYPE_INTER, palette mode can be used

[0482] a. In one example, when modeType is MODE_TYPE_INTRA, the chroma palette may be disabled.

[0483] b. In one example, when modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER, IBC mode may be allowed to be used.

[0484] c. In one example, regardless of modeType, IBC mode may be allowed.

[0485] d. In one example, when modeType is equal to MODE_TYPE_INTRA or MODE_TYPE_INTER, palette mode may be allowed.

[0486] e. In one example, regardless of modeType, palette mode may be allowed.

[0487] f. In one example, within one SCIPU, both palette and inter modes may be allowed.

[0488] g. In one example, within one SCIPU, palette, IBC and inter modes may all be allowed.

[0489] h. In one example, the size of a palette chroma block may always correspond to the size of the corresponding luma block.

[0490] i. In one example, when modeType is equal to MODE_TYPE_INTER and the codec unit size is 4x4 in luma, the signaling of pred_mode_plt_flag can be skipped and pred_mode_plt_flag can be inferred to be equal to 1.

[0491] j. In one example, when modeType is equal to MODE_TYPE_INTER and the codec unit size in luma is 4×4, a message may be sent to indicate whether the current prediction mode is IBC or palette.

[0492] k. In one example, whether to enable / disable palette mode may depend on the strip type and modeType.

[0493] i. In one example, for an I stripe with MODE_TYPE_INTRA, palette mode may be enabled.

[0494] ii. In one example, for a P / B strip with MODE_TYPE_INTER, palette mode may be enabled.

[0495] 19. When palette mode is enabled, local double trees can be disabled.

[0496] i. In one example, when palette mode is enabled, modeTypeCondition may always be set equal to 0.

[0497] 20. For small chroma blocks with width equal to M (e.g., M=2) or height equal to N (e.g., N=2), the allowed intra prediction modes may be restricted to be different from those allowed for large chroma blocks.

[0498] a. In one example, only a subset of the intra prediction modes of the available chroma intra prediction modes may be used.

[0499] b. In one example, only INTRA_DC mode may be used.

[0500] c. In one example, only INTRA_PLANAR mode may be used.

[0501] d. In one example, only INTRA_ANGULAR18 mode may be used.

[0502] e. In one example, only INTRA_ANGULAR50 mode may be used.

[0503] f. In one example, CCLM mode may be disabled.

[0504] 21. For small chroma blocks with width equal to M (e.g., M=2) or height equal to N (e.g., N=2), the transform types may be restricted to be different from those allowed for large chroma blocks.

[0505] a. In one example, only transform skipping may be used.

[0506] b. In one example, only one-dimensional transform may be used.

[0507] c. In one example, codecs that support multiple types of transforms are disabled.

[0508] i. Alternatively, signaling of codecs supporting multiple types of transforms is omitted.

[0509] 22.CIIP can be considered as MODE_TYPE_INTRA.

[0510] a. In one example, when dual-tree partitioning is used, CIIP mode may be allowed.

[0511] i. In one example, when the CU type is DUAL_TREEE_CHROMA, CIIP mode may be allowed.

[0512] b. Alternatively, CIIP can be viewed as MODE_TYPE_INTER

[0513] i. In one example, when the chroma block width is equal to M (eg, M=2), the CIIP mode may be disabled.

[0514] ii. In one example, when the chroma block width is equal to M (eg, M=2), the intra prediction mode for chroma in CIIP may be restricted to a simple intra prediction mode.

[0515] 1. In one example, when the chroma block width is equal to M (eg, M=2), INTRA_DC can be used for chroma intra prediction.

[0516] 2. In one example, when the chroma block width is equal to M (eg, M=2), INTRA_ANGULAR18 may be used for chroma intra prediction.

[0517] 3. In one example, when the chroma block width is equal to M (eg, M=2), INTRA_ANGULAR50 may be used for chroma intra prediction.

[0518] iii. In one example, the intra prediction mode for chroma in CIIP can be restricted to a simple intra prediction mode.

[0519] 1. In one example, INTRA_DC can be used for chroma intra prediction.

[0520] 2. In one example, INTRA_ANGULAR18 mode may be used for chroma intra prediction.

[0521] 3. In one example, INTRA_ANGULAR50 mode may be used for chroma intra prediction.

[0522] 23. For the above bullet points, variables M and / or N may be predefined or signaled.

[0523] a. In one example, M and / or N may further depend on the color format (eg, 4:2:0, 4:2:2, 4:4:4).

[0524] 24.modeType can be extended to cover more types.

[0525] a. In one example, modeType may be MODE_TYPE_IBC. When modeType is equal to MODE_TYPE_IBC, the prediction mode is inferred to be IBC.

[0526] i. In one example, in this case, pred_mode_flag is not signaled.

[0527] ii. In one example, in this case, pred_mode_ibc_flag is not signaled.

[0528] iii. In one example, in this case, pred_mode_plt_flag is not signaled.

[0529] b. In one example, modeType may be MODE_TYPE_PALETTE. When modeType is equal to MODE_TYPE_PALETTE, the prediction mode is inferred to be a palette mode.

[0530] i. In one example, in this case, pred_mode_flag is not signaled.

[0531] ii. In one example, in this case, pred_mode_ibc_flag is not signaled.

[0532] iii. In one example, in this case, pred_mode_plt_flag is not signaled.

[0533] c. In one example, mode_constraint_flag may be replaced by an index to indicate which allowed modeType to use.

[0534] 25. In one example, whether QT partitioning is allowed for a block of dimension W×H may depend on the modeType together with the dimension.

[0535] a. For example, if modeType is equal to MODE_TYPE_INTER and W is equal to 8 and H is equal to 8, QT splitting is disabled.

[0536] 26. In one example, whether vertical TT partitioning is allowed for a block of dimension W×H may depend on the modeType together with the dimension.

[0537] a. For example, if modeType is equal to MODE_TYPE_INTER and W is equal to 16 and H is equal to 4, vertical TT splitting is disabled.

[0538] 27. In one example, whether horizontal TT splitting is allowed for a block of dimension W×H may depend on the modeType together with the dimension.

[0539] a. For example, if modeType is equal to MODE_TYPE_INTER and W is equal to 4 and H is equal to 16, horizontal TT splitting is disabled.

[0540] 28. In one example, whether vertical BT splitting is allowed for a block of dimension W×H may depend on the modeType together with the dimension.

[0541] a. For example, if modeType is equal to MODE_TYPE_INTER and W is equal to 8 and H is equal to 4, vertical BT splitting is disabled.

[0542] 29. In one example, whether horizontal TT splitting is allowed for a block of dimension W×H may depend on the modeType together with the dimension.

[0543] a. For example, if modeType is equal to MODE_TYPE_INTER and W is equal to 4 and H is equal to 8, horizontal BT splitting is disabled.

[0544] 30. In one example, whether the prediction mode of a CU is inferred by modeType may depend on the color component and / or the block dimension W×H.

[0545] a. For example, the prediction mode of a chroma CU is inferred from modeType; but the prediction mode of a luma CU is signaled instead of inferred from modeType.

[0546] i. For example, if W>4 or H>4, the prediction mode of the luma CU is signaled instead of inferred by modeType.

[0547] 31. When SCIPU is applied, whether and / or how to signal the information related to the delta QP of the first component may depend on the partitioning manner of the first component.

[0548] a. In one example, when SCIPU is applied, whether and / or how to signal information related to the delta QP of the first component may depend on how the first component is partitioned and be decoupled from how the second component is partitioned.

[0549] b. In one example, the first component is luminance and the second component is chrominance.

[0550] c. In one example, the first component is chrominance and the second component is luminance.

[0551] 32. When dual-tree and / or partial dual-tree codec structures are applied, any variables related to the delta QP of the first component cannot be modified during the decoding or parsing process of the second component.

[0552] a. In one example, a local dual-tree codec structure may be used according to SCIPU.

[0553] b. In one example, the first component is luminance and the second component is chrominance.

[0554] i. The variable can be IsCuQpDeltaCoded.

[0555] c. In one example, the first component is chrominance and the second component is luminance.

[0556] i. The variable can be IsCuChromaQpOffsetCoded.

[0557] 33. When SCIPU is applied, information about the delta QP of a component (such as luma or chroma) is signaled at most once in a specific region where the luma component and the chroma component must share the same mode type (such as MODE_TYPE_INTER or MODE_TYPE_INTRA).

[0558] a. In one example, specific regions are considered as quantized groups.

[0559] 34. MxN chroma intra blocks with block width M and block height N may not be allowed.

[0560] a) In one example, DC prediction may be used for M×N chroma intra prediction, eg, M=2 chroma samples, N=8 and / or 16 and / or 32 chroma samples.

[0561] i. In one example, reconstructed neighboring pixels may not be used for DC prediction.

[0562] ii. In one example, the neighboring reference pixels may be set equal to 1<<(bitDepth-1) for DC prediction.

[0563] iii. In one example, PDPC may not be applied for DC prediction.

[0564] iv. In one example, DC mode information may not be encoded or decoded for MxN chroma intra blocks but may be derived.

[0565] b) In one example, CCLM prediction may be used for M×N chroma intra prediction, eg, M=2 chroma samples, N=8 and / or 16 and / or 32 chroma samples.

[0566] i. In one example, reconstructed neighboring pixels may not be used for CCLM prediction.

[0567] ii. In one example, for reconstructing the value rec from the chrominance L Export the chromaticity prediction value pred C CCLM prediction pred C =a*rec L +b, at the beginning of a video unit such as SPS / VPS / PPS / picture / sub-picture / slice / slice / brick / CTU row / CTU / VPDU / CU / PU / TU, parameters a and b may be initialized to default fixed values ​​(such as a=0, b=512).

[0568] 1. In one example, a FIFO table may be maintained on the fly to update CCLM parameters a and b.

[0569] iii. In one example, PDPC may not be applied to CCLM predictions.

[0570] iv. In one example, CCLM mode information may not be encoded or decoded for MxN chroma intra blocks but may be derived.

[0571] v. Alternatively, the proposed method can be applied to other kinds of CCLM-coded chroma blocks with width not equal to M or height not equal to N.

[0572] 1. In one example, CCLM parameters of a previously coded block may be used for the current block, rather than being derived based on reconstruction information of neighboring blocks of the current block.

[0573] 2. In one example, CCLM parameters may be stored in a table and updated on the fly, such as using a FIFO.

[0574] c) In one example, MxN chroma intra blocks may not be allowed in a dual tree, e.g., M=2 chroma samples, N=8 and / or 16 and / or 32 chroma samples.

[0575] i. In one example, when treeType is equal to DUAL_TREE_CHROMA, X-split can be disabled for codec tree nodes with dimensions equal to (M*a)x(N*b), where M*a is the width of the codec tree node in chroma samples and N*

[0576] b is the height of the codec tree node in chroma samples.

[0577] 1. In one example, X is a vertical BT partition, a=2, b=1

[0578] 2. In one example, X is a horizontal BT partition, a=1, b=2

[0579] 3. In one example, X is a vertical TT partition, a=4, b=1

[0580] 4. In one example, X is a horizontal TT partition, a=1, b=4

[0581] d) In one example, MxN chroma intra blocks may not be allowed in a single tree, e.g., M=2 chroma samples, N=8 and / or 16 and / or 32 chroma samples.

[0582] i. In one example, in a single tree, X-split may be disabled for chroma components of a codec tree node with dimensions equal to (M*a*subWidthC)x(N*b*subHeightC), where M*a is the width of the codec tree node in luma samples, N*b is the height of the codec tree node in luma samples, subWidthC and subHeightC are the chroma subsampling ratios in the width and height dimensions, e.g., for a 4:2:0 chroma format, subWidthC and subHeightC are equal to 2.

[0583] 1. In one example, X = vertical BT partition, a = 2, b = 1

[0584] 2. In one example, X = vertical TT partition, a = 4, b = 1

[0585] 3. In one example, X = horizontal BT partition, a = 1, b = 2

[0586] 4. In one example, X = horizontal TT partition, a = 1, b = 2

[0587] 5. In one example, X = horizontal TT partition, a = 1, b = 4

[0588] 6. In one example, the dimension of a non-partitioned chroma block may be equal to (M*a)×(N*d).

[0589] 7. In one example, a non-partitioned chroma block may be determined as MODE_TYPE_INTRA, and intra prediction (and / or IBC and / or PLT modes) may be allowed only for this chroma block.

[0590] 8. In one example, X-split may be allowed for the luma component of the codec tree node, for example, the luma codec tree node may be further divided into a plurality of luma sub-nodes, and each luma sub-node may be determined as MODE_TYPE_INTER, while only inter-frame prediction (and / or IBC mode) may be allowed.

[0591] 9. Alternatively, the chroma components may be further split along with the collocated luma component, but the mode type may be equal to MODE_TYPE_INTER and only inter prediction (and / or IBC mode) may be allowed.

[0592] ii. In one example, MxN chroma intra blocks may not be allowed in CIIP.

[0593] 1. In one example, CIIP may not be allowed for codec blocks with dimensions equal to (M*subWidthC)x(N*subHeightC) in luma samples.

[0594] a) When CIIP is not allowed, the associated syntax elements (such as the CIIP flag) may not be encoded in the bitstream.

[0595] 2. In one example, the chroma blending process in CIIP can be filled with predictions from the inter part only.

[0596] a) In one example, only luma intra prediction may be applied to CIIP coded blocks, while chroma intra prediction may not be applied to CIIP coded blocks with dimensions equal to (M*subWidthC)x(N*subHeightC) in luma samples.

[0597] 3. In one example, DC prediction may be used for MxN chroma intra prediction of CIIP blocks, as described in bullet 34(a).

[0598] 4. In one example, CCLM prediction can be used for M×N chroma intra prediction of CIIP blocks, as described in bullet point 34(b).

[0599] Relationship between lessSizeY and maxCTB / maxTBsize / maxTS sizes 35. For lossless (and / or near-lossless codecs) and lossy codecs, the maximum transform size may be signaled and / or inferred in different ways.

[0600] a. In one example, since no transform is involved, the maximum transform size of lossless and / or near-lossless codec may be referred to by other terms, such as “maximum residual size” or “maximum representation size”. In the present disclosure, it may be referred to as “maxLosslessTbSizeY”.

[0601] b. In one example, lossless encoding of a block may be indicated by cu_transquant_bypass_flag being equal to 1 for the block.

[0602] c. In one example, a near-lossless codec of a block may be referred to as a codec with a QP less than a given threshold.

[0603] i. In one example, the threshold may be indicated in the DPS / VPS / SPS / PPS / slice / stripe / brick header.

[0604] d. In one example, a near-lossless codec for a block may be referred to as a codec with a QP less than a given threshold, and transform_skip_flag is equal to 1 for the block.

[0605] i. In one example, the threshold may be indicated in the DPS / VPS / SPS / PPS / slice / stripe / brick header.

[0606] e. A first maximum transform size for lossless and / or near-lossless codec (eg, maxLosslessTbSizeY) may be set conditioned on a second maximum transform size and / or a maximum codec tree unit size and / or a maximum transform skip size that may be used for lossy codecs.

[0607] f. The maximum transform size for lossless and / or near-lossless codecs may be signaled at the video unit level in syntax elements (SE) such as SPS / VPS / PPS / sub-picture / slice / slice / brick / CTU / VPDU.

[0608] i. In one example, the SE may be signaled depending on the maximum CTB size (eg, log2_ctu_size_minus5, CtbSizeY, etc.).

[0609] 1. For example, when log2_ctu_size_minus5 is greater than N (such as, N=0), a flag may be signaled.

[0610] ii. In one example, the SE may be signaled depending on the maximum transform size (eg, sps_max_luma_transform_size_64_flag, MaxTbSize, etc.).

[0611] 1. For example, when sps_max_luma_transform_size_64_flag is equal to M (such as M=1), the SE may be signaled.

[0612] iii. In one example, the SE may be signaled depending on the maximum transform skip size (eg, log2_transform_skip_max_size_minus2, MaxTsSize, etc.).

[0613] 1. For example, when log2_transform_skip_max_size_minus2 is greater than K (such as K=3), the SE may be signaled.

[0614] iv. In one example, the delta value between log(maxLosslessTbSizeY) and X may be signaled.

[0615] 1. For example, X can be equal to log2_ctu_size_minus5

[0616] 2. For example, X can be equal to sps_max_luma_transform_size_64_flag

[0617] 3. For example, X can be equal to log2_transform_skip_max_size_minus2

[0618] 4. For example, X can be equal to a fixed integer.

[0619] 5. In one example, delta - K may be signaled, where K is an integer, such as 1.

[0620] v. In one example, the incremental value between maxLosslessTbSizeY and X may be signaled.

[0621] 1. For example, X can be equal to CtbSizeY

[0622] 2. For example, X can be equal to MaxTbSize

[0623] 3. For example, X can be equal to MaxTsSize

[0624] 4. For example, X can be equal to a fixed integer.

[0625] 5. In one example, delta - K may be signaled, where K is an integer, such as 1.

[0626] vi. In one example, the maxLosslessTbSizeY of a video unit (such as sequence / picture / sub-picture / slice / slice / CTU / VPDU / CU / PU / TU) can be derived from SE.

[0627] vii.SE can be a logo.

[0628] viii. When the flag is not present, it can be inferred to be equal to the positive integer N.

[0629] g. In one example, if lossless and / or near-lossless codec is applied to a video unit (such as cu_transquant_bypass_flag equal to 1), the maximum transform size of the video unit may be set equal to maxLosslessTbSizeY instead of maxTbSizeY.

[0630] h. Alternatively, the maximum transform size for lossless and / or near-lossless codecs of video units (such as sequence / picture / sub-picture / slice / slice / CTU / VPDU / CU / PU / TU) may be derived instead of signaled.

[0631] i. For example, it may be set equal to a fixed integer value M (such as M=32 in luma samples).

[0632] ii. For example, it can be set equal to the second largest transform size available for lossy codecs

[0633] iii. For example, it can be set equal to the maximum codec tree unit size,

[0634] iv. For example, it can be set equal to the VPDU size,

[0635] v. For example, it can be set equal to the maximum transform skip block size.

[0636] vi. For example, it can be set equal to the maximum residual codec block size.

[0637] 36. For an MxN residual block passed through lossless codec (and / or near-lossless codec), it can be split into more than one smaller residual sub-block depending on maxLosslessTbSizeY.

[0638] a. After splitting, the width and height of all sub-blocks are no greater than maxLosslessTbSizeY.

[0639] b. In one example, it can be split into sub-blocks in a recursive manner until the width and height of all sub-blocks are no greater than maxLosslessTbSizeY.

[0640] Deblocking related

[0641] 37. Palette mode can be enabled in MODE_TYPE_ALL or MODE_TYPE_INTRA, but is always disabled in MODE_TYPE_INTER.

[0642] 38. When one side is in IBC mode and the other side is in palette mode, the deblocking boundary strength (bs) of the chroma component can be set to 0.

[0643] a. In one example, when one side is in IBC mode and the other side is in palette mode, bS of the chroma component is set to 0 when ChromaArrayType is not equal to 0.

[0644] The minimum allowed QP of a transform skip block is related to

[0645] 39. The syntax element from which the input bit depth can be inferred (eg internal_minus_input_bit_depth as shown in JVET-R0045) can be constrained according to a certain profile.

[0646] a. In one example, in a 10-bit profile, (QpPrimeTsMin–4) / 6 may be constrained to be in the range of [0,2].

[0647] b. In one example, in an 8-bit profile, (QpPrimeTsMin–4) / 6 may be constrained to be 0.

[0648] c. In one example, in a (K+8)-bit profile, (QpPrimeTsMin−4) / 6 can be constrained to be within [0, K].

[0649] d. In one example, in a (K+8)-bit profile, (QpPrimeTsMin−4) / 6 can be constrained to be within [0, K].

[0650] 40. The minimum allowed QP (e.g., QpPrimeTsMin) can be constrained according to a certain summary table.

[0651] a. In one example, in a 10-bit profile, (QpPrimeTsMin–4) / 6 may be constrained to be in the range of [0,2].

[0652] b. In one example, in an 8-bit profile, (QpPrimeTsMin–4) / 6 may be constrained to be 0.

[0653] c. In one example, in a (K+8)-bit profile, (QpPrimeTsMin−4) / 6 can be constrained to be within [0, K].

[0654] d. In one example, in a (K+8)-bit profile, (QpPrimeTsMin−4) / 6 can be constrained to be within [0, K].

[0655] 5. Examples

[0656] The newly added part , and sections removed from the VVC working draft are marked with double brackets (e.g. Indicates deleting the character "a"). Modification is based on the latest VVC working draft (JVET-O2001-v11)

[0657] 5.1 Example Embodiment #1

[0658]

[0659] 7.4.9.4 Codec Tree Semantics

[0660] The variable modeTypeCondition is derived as follows:

[0661] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0662] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0663] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0664]

[0665] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0666] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0667] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0668] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0669] – Otherwise, if one of the following conditions is true, then modeTypeCondition is set equal to 1 + (slice_type != I? 1:0)

[0670] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0671] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0672] – Otherwise, set modeTypeCondition equal to 0

[0673] 5.2 Example Embodiment #2

[0674] The following embodiments relate to: The signaling notification of the palette mode flag does not depend on the modeType.

[0675] 7.3.8.5 Codec unit syntax

[0676]

[0677]

[0678] 5.3 Example Embodiment #3

[0679]

[0680] pred_mode_ibc_flag equal to 1 specifies that the current codec unit is coded in IBC prediction mode. pred_mode_ibc_flag equal to 0 specifies that the current codec unit is not coded in IBC prediction mode.

[0681] When pred_mode_ibc_flag is not present, the inference is as follows:

[0682] – If cu_skip_flag[x0][y0] is equal to 1, and cbWidth is equal to 4, and cbHeight is equal to 4, then pred_mode_ibc_flag is inferred to be equal to 1.

[0683] – Otherwise, if cbWidth and cbHeight are both equal to 128, pred_mode_ibc_flag is inferred to be equal to 0.

[0684] –[[Otherwise, if cu_skip_flag[x0][y0] is equal to 1, and modeType is equal to MODE_TYPE_INTRA, then pred_mode_ibc_flag is inferred to be equal to 1. ]]

[0685] – Otherwise, if modeType is equal to MODE_TYPE_INTER, pred_mode_ibc_flag is inferred to be equal to 0.

[0686] – Otherwise, if treeType is equal to DUAL_TREE_CHROMA, pred_mode_ibc_flag is inferred to be equal to 0.

[0687] – Otherwise, pred_mode_ibc_flag is inferred to be equal to the value of sps_ibc_enabled_flag when decoding I slices and to be equal to 0 when decoding P or B slices, respectively.

[0688] When pred_mode_ibc_flag is equal to 1, for x=x0..x0+cbWidth−1 and y=y0..y0+cbHeight−1, the variable CuPredMode[chType][x][y] is set equal to MODE_IBC.

[0689] 5.4 Example Embodiment #4

[0690]

[0691] 7.3.8.5 Codec unit syntax

[0692]

[0693] 5.5 Example Embodiment #5

[0694]

[0695] 7.4.9.4 Codec Tree Semantics

[0696] The variable modeTypeCondition is derived as follows:

[0697] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0698] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0699] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0700] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0701] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0702] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0703] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0704] – Otherwise, if one of the following conditions is true, then modeTypeCondition is set equal to 1 + (slice_type != I? 1:0)

[0705] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER,

[0706] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER,

[0707] – Otherwise, set modeTypeCondition equal to 0

[0708] 5.6 Example Embodiment #6

[0709] The following embodiments relate to disabling 2xN chroma intra blocks in a single tree.

[0710] 7.4.9.4 Codec Tree Semantics

[0711] The variable modeTypeCondition is derived as follows:

[0712] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0713] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0714] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0715] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0716] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0717] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0718] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0719] – Otherwise, if one of the following conditions is true, then modeTypeCondition is set equal to 1 + (slice_type != I? 1:0)

[0720] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0721] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0722]

[0723] – Otherwise, set modeTypeCondition equal to 0

[0724] 5.7 Example Embodiment #7

[0725] The following embodiments relate to disabling 2xN chroma intra blocks in a dual tree.

[0726] 6.4.2 Allowed binary partitioning procedures

[0727] The variable allowBtSplit is exported as follows:

[0728] – Set allowBtSplit equal to false if one or more of the following conditions are true:

[0729] –cbSize is less than or equal to MinBtSizeY

[0730] –cbWidth is greater than maxBtSize

[0731] –cbHeight is greater than maxBtSize

[0732] –mttDepth is greater than or equal to maxMttDepth

[0733] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0734]

[0735]

[0736] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0737] …

[0738] 6.4.3 Allowed ternary partitioning process

[0739] The variable allowTtSplit is exported as follows:

[0740] – Set allowTtSplit equal to false if one or more of the following conditions are true:

[0741] –cbSize is less than or equal to 2*MinTtSizeY

[0742] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0743] –cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0744] –mttDepth is greater than or equal to maxMttDepth

[0745] –x0+cbWidth is greater than pic_width_in_luma_samples

[0746] –y0+cbHeight is greater than pic_height_in_luma_samples

[0747] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0748]

[0749] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0750] – Otherwise, set allowTtSplit equal to true.

[0751] 5.8 Example Embodiment #8

[0752] The following embodiments relate to: enabling MODE_IBC for SCIPU chroma blocks.

[0753] 7.3.8.5 Codec unit syntax

[0754]

[0755]

[0756] 5.9 Example Implementation #9, Block Splitting Disabled When ModeType is MODE_TYPE_INTER (Solution 1)

[0757] 6.4.2 Allowed binary partitioning procedures

[0758] The variable allowBtSplit is exported as follows:

[0759] – Set allowBtSplit equal to false if one or more of the following conditions are true:

[0760] –cbSize is less than or equal to MinBtSizeY

[0761] –cbWidth is greater than maxBtSize

[0762] –cbHeight is greater than maxBtSize

[0763] –mttDepth is greater than or equal to maxMttDepth

[0764] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0765]

[0766] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0767] …

[0768] 6.4.3 Allowed ternary partitioning process

[0769] The variable allowTtSplit is exported as follows:

[0770] – Set allowTtSplit equal to false if one or more of the following conditions are true:

[0771] –cbSize is less than or equal to 2*MinTtSizeY

[0772] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0773] –cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0774] –mttDepth is greater than or equal to maxMttDepth

[0775] –x0+cbWidth is greater than pic_width_in_luma_samples

[0776] –y0+cbHeight is greater than pic_height_in_luma_samples

[0777] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0778]

[0779] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0780] – Otherwise, set allowTtSplit equal to true.

[0781] 5.10 Example Embodiment #10, Block Splitting Disabled When modeType is MODE_TYPE_INTER (Solution 2)

[0782] 6.4.2 Allowed binary partitioning procedures

[0783] The variable allowBtSplit is exported as follows:

[0784] – Set allowBtSplit equal to false if one or more of the following conditions are true:

[0785] –cbSize is less than or equal to MinBtSizeY

[0786] –cbWidth is greater than maxBtSize

[0787] –cbHeight is greater than maxBtSize

[0788] –mttDepth is greater than or equal to maxMttDepth

[0789] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0790]

[0791] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0792] …

[0793] 6.4.3 Allowed ternary partitioning process

[0794] The variable allowTtSplit is exported as follows:

[0795] – Set allowTtSplit equal to false if one or more of the following conditions are true:

[0796] –cbSize is less than or equal to 2*MinTtSizeY

[0797] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0798] –cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0799] –mttDepth is greater than or equal to maxMttDepth

[0800] –x0+cbWidth is greater than pic_width_in_luma_samples

[0801] –y0+cbHeight is greater than pic_height_in_luma_samples

[0802] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0803]

[0804] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0805] – Otherwise, set allowTtSplit equal to true.

[0806] 5.11 Example Embodiment #11

[0807] The following embodiments are about constraints on further partitioning of the codec tree when deriving MODE_TYPE_INTER.

[0808] 7.3.8.4 Codec Tree Syntax

[0809]

[0810] 5.12 Example Embodiment #12

[0811] The following embodiments are about the constraints of tile partitioning, and the prediction mode is not applied when the palette mode is enabled.

[0812] 7.4.9.4 Codec Tree Semantics

[0813] The variable modeTypeCondition is derived as follows:

[0814] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0815] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0816] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0817]

[0818] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0819] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0820] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0821] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0822] – Otherwise, if one of the following conditions is true, then modeTypeCondition is set equal to 1 + (slice_type != I? 1:0)

[0823] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0824] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0825] – Otherwise, set modeTypeCondition equal to 0

[0826] 5.13 Example Embodiment #13

[0827] The following embodiments are about small chroma intra block constraints for 4:2:2 color format.

[0828] 7.4.9.4 Codec Tree Semantics

[0829] The variable modeTypeCondition is derived as follows:

[0830] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0831] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0832] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0833] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0834] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0835] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0836] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0837] – Otherwise, if and one of the following conditions is true, then modeTypeCondition is set equal to 1+(slice_type!=I?1:0)

[0838] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0839] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0840] – Otherwise, set modeTypeCondition equal to 0

[0841] 5.14 Example #1 of incremental QP signaling in SCIPU

[0842]

[0843]

[0844]

[0845] 5.15 Example #2 of incremental QP signaling in SCIPU

[0846]

[0847]

[0848]

[0849] 5.16 Example #3 of incremental QP signaling in SCIPU

[0850]

[0851]

[0852]

[0853] 5.17 Example #4 of incremental QP signaling in SCIPU

[0854]

[0855]

[0856]

[0857] 5.18 Example #14 of disabling 2x8 chroma intra blocks

[0858] 6.4.2 Allowed binary partitioning procedures

[0859] The variable allowBtSplit is exported as follows:

[0860] – Set allowBtSplit equal to false if one or more of the following conditions are true:

[0861] –cbSize is less than or equal to MinBtSizeY

[0862] –cbWidth is greater than maxBtSize

[0863] –cbHeight is greater than maxBtSize

[0864] –mttDepth is greater than or equal to maxMttDepth

[0865] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 16

[0866]

[0867] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0868] …

[0869] 6.4.3 Allowed ternary partitioning process

[0870] The variable allowTtSplit is exported as follows:

[0871] – Set allowTtSplit equal to false if one or more of the following conditions are true:

[0872] –cbSize is less than or equal to 2*MinTtSizeY

[0873] –cbWidth is greater than Min(MaxTbSizeY, maxTtSize)

[0874] –cbHeight is greater than Min(MaxTbSizeY, maxTtSize)

[0875] –mttDepth is greater than or equal to maxMttDepth

[0876] –x0+cbWidth is greater than pic_width_in_luma_samples

[0877] –y0+cbHeight is greater than pic_height_in_luma_samples

[0878] –treeType is equal to DUAL_TREE_CHROMA, and (cbWidth / SubWidthC)*(cbHeight / SubHeightC) is less than or equal to 32

[0879]

[0880] –treeType equals DUAL_TREE_CHROMA and modeType equals MODE_TYPE_INTRA

[0881] – Otherwise, set allowTtSplit equal to true.

[0882] 7.4.9.4 Codec Tree Semantics

[0883] The variable modeTypeCondition is derived as follows:

[0884] – If one of the following conditions is true, then set modeTypeCondition equal to 0

[0885] – slice_type == 1, and qtbtt_dual_tree_intra_flag is equal to 1

[0886] –modeTypeCurr is not equal to MODE_TYPE_ALL

[0887] – Otherwise, if one of the following conditions is true, then set modeTypeCondition equal to 1

[0888] –cbWidth*cbHeight is equal to 64, and split_qt_flag is equal to 1

[0889] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0890] –cbWidth*cbHeight is equal to 32, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0891] – Otherwise, if one of the following conditions is true, then modeTypeCondition is set equal to 1 + (slice_type != I? 1:0)

[0892] –cbWidth*cbHeight is equal to 64, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_BT_HOR or SPLIT_BT_VER

[0893] –cbWidth*cbHeight is equal to 128, and MttSplitMode[x0][y0][mttDepth] is equal to SPLIT_TT_HOR or SPLIT_TT_VER

[0894]

[0895] – Otherwise, set modeTypeCondition equal to 0

[0896] 7.4.9.7 Merge Data Semantics

[0897] ciip_flag[x0][y0] specifies whether combined inter-picture Merge and intra-picture prediction is applied to the current codec unit. Array index x0, y0 specifies the position (x0, y0) of the upper left luma sample of the considered codec block relative to the upper left luma sample of the picture.

[0898] When ciip_flag[x0][y0] does not exist, the inference is as follows:

[0899] – ciip_flag[x0][y0] is inferred to be equal to 1 if all of the following are true:

[0900] –sps_ciip_enabled_flag is equal to 1.

[0901] –general_merge_flag[x0][y0] is equal to 1.

[0902] –merge_subblock_flag[x0][y0] is equal to 0.

[0903] –regular_merge_flag[x0][y0] is equal to 0.

[0904] –cbWidth is less than 128.

[0905] –cbHeight is less than 128.

[0906]

[0907] –cbWidth*cbHeight is greater than or equal to 64.

[0908] – Otherwise, ciip_flag[x0][y0] is inferred to be equal to 0.

[0909] 7.3.8.7 Merge Data Syntax

[0910]

[0911] 5.18 Example of setting the chroma deblocking boundary strength to 0

[0912] Below, changes, newly added parts are marked in bold and italics, and deleted parts are marked with double brackets (eg, [[a]] indicates deletion of the character "a"). Modifications are based on JVET-Q2001-vE.

[0913] 8.8.3.5 Derivation process of boundary filter strength

[0914] …

[0915] For xD i (where i = 0..xN) and yD j (where j = 0..yN), the following applies:

[0916] – If edgeFlags[xD i ][yD j ] is equal to 0, then the variable bS[xD i ][yD j ] is set equal to 0.

[0917] – Otherwise, the following applies:

[0918] – The sample point values ​​p0 and q0 are derived as follows:

[0919] – If edgeType is equal to EDGE_VER, then p0 is set equal to recPicture[xCb+xD i -1][yCb+yD j ], and q0 is set equal to recPicture[xCb+xD i ][yCb+yD j ].

[0920] – Otherwise (edgeType equals EDGE_HOR), p0 is set equal to recPicture[xCb+xD i ][yCb+yD j -1], and q0 is set equal to recPicture[xCb+xD i ][yCb+yD j ].

[0921] –Variable bS[xD i ][yD j ] is exported as follows:

[0922] – If cIdx is equal to 0, and samples p0 and q0 are both in the codec block with intra_bdpcm_luma_flag equal to 1, then bS[xD i ][yD j ] is set equal to 0.

[0923] – Otherwise, if cIdx is greater than 0, and samples p0 and q0 are both in the codec block with intra_bdpcm_chroma_flag equal to 1, then bS[xD i ][yD j ] is set equal to 0.

[0924] – Otherwise, if the sample p0 or q0 is in the codec block of a codec unit coded in intra prediction mode, then bS[xD i ][yD j ] is set equal to 2.

[0925] – Otherwise, if the block edge is also a codec block edge, and sample p0 or q0 is in a codec block with ciip_flag equal to 1, then bS[xD i ][yD j ] is set equal to 2.

[0926] – Otherwise, if the block edge is also a transform block edge, and sample p0 or q0 is in a transform block containing one or more non-zero transform coefficient levels, then bS[xD i ][yD j ] is set equal to 1.

[0927] –[[Otherwise, if the prediction mode of the coded subblock containing sample p0 is different from the prediction mode of the coded subblock containing sample q0 (i.e., one coded subblock is coded in IBC prediction mode and the other in inter prediction mode), then bS[xD i ][yD j ] is set equal to 1. ]]

[0928] – Otherwise, if cIdx is equal to 0, edgeFlags[xD i ][yD j ] is set equal to 2, and one or more of the following conditions are true, then bS[xD i ][yD j ] is set equal to 1:

[0929]

[0930] – The codec sub-block containing sample p0 and the codec sub-block containing sample q0 are both coded in IBC prediction mode, and the absolute difference between the horizontal or vertical components of the block vectors used in the prediction of the two codec sub-blocks is greater than or equal to 8 in units of 1 / 16 luma samples.

[0931] – For the prediction of the codec sub-block containing sample p0, a different reference picture or a different number of motion vectors is used compared to the prediction of the codec sub-block containing sample q0.

[0932] NOTE 1 – Determining whether the reference pictures used for two codec sub-blocks are the same or different is based solely on which pictures are referenced, regardless of whether an index from reference picture list 0 or an index from reference picture list 1 is used to form the prediction, or whether the index positions within the reference picture lists are different.

[0933] NOTE 2 – The number of motion vectors used for the prediction of the coded sub-block for the top left sample coverage (xSb, ySb) is equal to PredFlagL0[xSb][ySb]+PredFlagL1[xSb][ySb].

[0934] – One motion vector is used to predict the codec sub-block containing sample p0, and one motion vector is used to predict the codec sub-block containing sample q0, and the absolute difference between the horizontal or vertical components of the used motion vectors is greater than or equal to 8 in units of 1 / 16 luma samples.

[0935] – Two motion vectors and two different reference pictures are used to predict the codec sub-block containing sample p0, two motion vectors of the same two reference pictures are used to predict the codec sub-block containing sample q0, and the absolute difference between the horizontal or vertical components of the two motion vectors used in the prediction of the two codec sub-blocks of the same reference picture is greater than or equal to 8 in units of 1 / 16 luma samples.

[0936] – Two motion vectors from the same reference picture are used to predict the codec sub-block containing sample p0, and two motion vectors from the same reference picture are used to predict the codec sub-block containing sample q0, and both of the following conditions are true:

[0937] – The absolute difference between the horizontal or vertical components of the list 0 motion vectors used in the prediction of the two codec sub-blocks is greater than or equal to 8 in units of 1 / 16 luma samples, or the absolute difference between the horizontal or vertical components of the list 1 motion vectors used in the prediction of the two codec sub-blocks is greater than or equal to 8 in units of 1 / 16 luma samples.

[0938] – the absolute difference between the horizontal or vertical component of the list 0 motion vector used in the prediction of the codec sub-block containing sample p0 and the list 1 motion vector used in the prediction of the codec sub-block containing sample q0 is greater than or equal to 8 in units of 1 / 16 luma samples, or the absolute difference between the horizontal or vertical component of the list 1 motion vector used in the prediction of the codec sub-block containing sample p0 and the list 0 motion vector used in the prediction of the codec sub-block containing sample q0 is greater than or equal to 8 in units of 1 / 16 luma samples.

[0939] – Otherwise, the variable bS[xD i ][yD j ] is set equal to 0.

[0940] Fig.17A 1 is a block diagram of a video processing device 1700. The device 1700 may be used to implement one or more of the methods described herein. The device 1700 may be implemented in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. The device 1700 may include one or more processors 1702, one or more memories 1704, and video processing hardware 1706. The processor(s) 1702 may be configured to implement one or more of the methods described in this document. The memory(s) 1704 may be used to store data and code for implementing the methods and techniques described herein. The video processing hardware 1706 may be used to implement some of the techniques described in this document in hardware circuits.

[0941] Fig. 17B is another example of a block diagram of a video processing system that may implement the disclosed technology. Fig. 17B 17 is a block diagram illustrating an example video processing system 1710 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1710. System 1710 may include an input 1712 for receiving video content. The video content may be received in a raw or uncompressed format (e.g., 8 or 10 bit multi-component pixel values), or may be received in a compressed or encoded format. Input 1712 may represent a network interface, a peripheral bus interface, or a storage interface. Examples of network interfaces include wired interfaces (such as Ethernet, passive optical networks (PONs), etc.) and wireless interfaces (such as Wi-Fi or cellular interfaces).

[0942] System 1710 may include a codec component 1714 that may implement various codecs or encoding methods described in this document. Codec component 1714 may reduce the average bit rate of a video from input 1712 to the output of codec component 1714 to generate a codec representation of the video. Therefore, codec technology is sometimes referred to as video compression or video transcoding technology. As represented by component 1716, the output of codec component 1714 may be stored or transmitted via a connected communication. The stored or transmitted bitstream (or codec) representation of the video received at input 1712 may be used by component 1718 to generate pixel values ​​or displayable video that is sent to display interface 1720. The process of generating user-visible video from a bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it should be understood that codec tools or operations are used at the encoder, and corresponding decoding tools or operations that will make the codec results opposite will be performed by the decoder.

[0943] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB) or High Definition Multimedia Interface (HDMI) or DisplayPort, etc. Examples of storage interfaces include SATA (Serial Advanced Technology Attachment), PCI, IDE interfaces, etc. The technology described in this document may be implemented in various electronic devices, such as mobile phones, laptop computers, smart phones, or other devices capable of performing digital data processing and / or video display.

[0944] Fig.21 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure.

[0945] like Fig.21 As shown, the video coding system 100 may include a source device 110 and a target device 120. The source device 110 generates encoded video data, and the source device 110 may be referred to as a video coding device. The target device 120 may decode the encoded video data generated by the source device 110, and the target device 120 may be referred to as a video decoding device.

[0946] Source device 110 may include a video source 112 , a video encoder 114 , and an input / output (I / O) interface 116 .

[0947] The video source 112 may include a source such as a video capture device, an interface for receiving video data from a video content provider and / or a computer graphics system for generating video data, or a combination of these sources. 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 bit stream. The bit stream may include a bit sequence that forms a codec representation of the video data. The bit stream may include a codec picture and associated data. The codec picture is a codec representation of the picture. The associated data may include a sequence parameter set, a picture parameter set, and other grammatical structures. The I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The encoded video data may be directly transmitted to the target device 120 via the network 130a via the I / O interface 116. The encoded video data may also be stored on a storage medium / server 130b for access by the target device 120.

[0948] Target device 120 may include an I / O interface 126 , a video decoder 124 , and a display device 122 .

[0949] The I / O interface 126 may include a receiver and / or a modem. The I / O interface 126 may obtain coded video data from the source device 110 or the storage medium / server 130b. The video decoder 124 may decode the coded video data. The display device 122 may display the decoded video data to the user. The display device 122 may be integrated with the target device 120, or may be outside the target device 120 configured to interface with an external display device.

[0950] 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 current and / or future standards.

[0951] Fig. 22 is a block diagram illustrating an example of a video encoder 200, which may be Fig.21 The video encoder 114 in the system 100 is shown.

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

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

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

[0955] Furthermore, some components such as the motion estimation unit 204 and the motion compensation unit 205 may be highly integrated, but for the purpose of explanation, they are described in detail in the following sections. Fig. 22 In the example, they are shown separately.

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

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

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

[0959] Motion estimation unit 204 and motion compensation unit 205 may perform different operations on the current video block, eg, depending on whether the current video block is an I slice, a P slice, or a B slice.

[0960] In some examples, the motion estimation unit 204 may perform unidirectional prediction on the current video block, and the motion estimation unit 204 may search for a reference video block of the current video block in the reference picture of list 0 or list 1. The motion estimation unit 204 may then generate a reference index indicating a reference picture in list 0 or list 1, which list 0 or list 1 contains the reference video block and a motion vector indicating a spatial displacement between the current video block and the reference video block. The motion estimation unit 204 may output the reference index, the prediction direction indicator, and the motion vector as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block of the current block based on the reference video block indicated by the motion information of the current video block.

[0961] In other examples, the motion estimation unit 204 may perform bidirectional prediction on the current video block, and the motion estimation unit 204 may search for a reference video block of the current video block in the reference pictures in list 0, and may also search for another reference video block of the current video block in the reference pictures in list 1. Then, the motion estimation unit 204 may generate a reference index indicating the reference pictures in list 0 and list 1, which list 0 and list 1 contain reference video blocks and motion vectors indicating spatial displacements between the reference video blocks and the current video block. The motion estimation unit 204 may output the reference index and the motion vector of the current video block as motion information of the current video block. The motion compensation unit 205 may generate a predicted video block of the current video block based on the reference video block indicated by the motion information of the current video block.

[0962] In some examples, motion estimation unit 204 may output a complete set of motion information for use in a decoding process of a decoder.

[0963] In some examples, motion estimation unit 204 may not output a complete set of motion information for the current video. Instead, motion estimation unit 204 may reference motion information of another video block to signal the motion information of the current 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 a neighboring video block.

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

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

[0966] As described above, the video encoder 200 may predictively signal motion vectors. Two examples of predictive signaling techniques that may be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and Merge mode signaling.

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

[0968] The residual generation unit 207 may 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.

[0969] In other examples, for the current video block, 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.

[0970] 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 a residual video block associated with the current video block.

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

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

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

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

[0975] Fig.23 is a block diagram illustrating an example of a video decoder 300, which may be Fig.21 The video decoder 114 in the system 100 is shown.

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

[0977] exist Fig.23 In the example of FIG. 3 , the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 may perform operations generally similar to those performed with respect to the video encoder 200 (e.g., Fig. 22 ) is the reverse of the encoding and decoding traversal described in .

[0978] The entropy decoding unit 301 may retrieve an encoded bitstream. The encoded bitstream may include entropy-encoded video data (e.g., encoded blocks of video data). The entropy decoding unit 301 may decode the entropy-encoded video data, and the motion compensation unit 302 may determine motion information including motion vectors, motion vector precision, reference picture list indexes, and other motion information from the entropy-decoded video data. The motion compensation unit 302 may determine such information, for example, by performing AMVP and Merge modes.

[0979] The motion compensation unit 302 may generate a motion compensated block, possibly performing interpolation based on an interpolation filter. An identifier of an interpolation filter to be used with sub-pixel precision may be included in the syntax element.

[0980] Motion compensation unit 302 may use the interpolation filters used by video encoder 20 during encoding of the video block to calculate interpolation of sub-integer pixels of the reference block. Motion compensation unit 302 may determine the interpolation filters used by video encoder 200 according to received syntax information and use the interpolation filters to generate a prediction block.

[0981] The motion compensation unit 302 may use some syntax information to determine the size of blocks used to encode (one or more) frames and / or (one or more) slices of the encoded video sequence, partitioning information describing how each macroblock of a picture of the encoded video sequence is partitioned, a mode indicating how each partition is encoded, one or more reference frames (and reference frame lists) for each inter-frame coded block, and other information for decoding the encoded video sequence.

[0982] The intra prediction unit 303 may use, for example, an intra prediction mode received in the bitstream to form a prediction block from spatially adjacent blocks. The inverse quantization unit 303 inversely 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 303 applies an inverse transform.

[0983] The reconstruction unit 306 may add the residual block to the corresponding prediction block generated by the motion compensation unit 202 or the intra prediction unit 303 to form a decoded block. If necessary, a deblocking filter may also be applied to filter the decoded block to remove block artifacts. The decoded video block is then stored in a buffer 307, which provides a reference block for subsequent motion compensation.

[0984] Fig.18 1800 is a flow chart of a method 1800 for processing a video. The method 1800 includes: 1802, for conversion between a video region of a video and a codec representation of the video region, parsing the codec representation according to a grammar rule, the grammar rule defining a relationship between a chroma block size and a color format of the video region; 1804, performing conversion by performing the parsing according to the grammar rule.

[0985] A list of examples of some preferred embodiments is provided below.In this document, a video region may be a codec block or a slice or a codec tree unit or a prediction block or a transform block.

[0986] The first set of clauses illustrates example embodiments of the techniques discussed in the previous section.The following clauses can be implemented with the additional techniques described in item 1 of the previous section.

[0987] 1. A method for video processing, comprising: for conversion between a video region of a video and a codec representation of the video region, parsing the codec representation according to a grammar rule, the grammar rule defining a relationship between a chroma block size and a color format of the video region; and performing the conversion by performing the parsing according to the grammar rule.

[0988] 2. A method according to clause 1, wherein the color format is 4:4:4, and wherein the syntax rules specify that the chroma blocks are subject to the same size constraints as the luma blocks.

[0989] 3. A method according to clause 1, wherein the color format is 4:2:2, and wherein the syntax rules specify that the chroma blocks are subject to the same size constraints as the 4:2:0 color format.

[0990] 4. A method according to any of clauses 1-3, wherein the syntax specifies the use of prediction modes and tile partitioning in a manner that depends on the chroma format.

[0991] 5. The method of clause 1, wherein the grammar rule defines a minimum allowed size feature to enable conversion of the video region based on a color format of the video region.

[0992] The following items can be implemented in conjunction with the additional techniques described in item 2 of the previous section.

[0993] 6. A method for video processing, comprising: determining a codec mode of a codec tree node of the video based on attributes of the video and a chroma format of the video; and using the determined codec mode to perform conversion between a codec representation of the video and a video block of the codec tree node.

[0994] 7. A method according to clause 6, wherein the codec mode is determined to be MODE_TYPE_ALL for the chroma format being 4:2:2 and MODE_TYPE_INTRA or MODE_TYPE_INTER for the chroma format being 4:2:0, when the attribute is:

[0995] i. The codec node is an MxN codec tree node having a horizontal binary tree partition;

[0996] ii. The codec node is an MxN codec tree node having a vertical binary tree partition;

[0997] iii. The codec node is an MxN codec tree node having a horizontal ternary tree partition; or

[0998] iv. The codec node is an MxN codec tree node with vertical ternary tree partitioning.

[0999] 8. The method of clause 7, wherein M=8 or 16 or 32, and N=4 or 8 or 16.

[1000] The following items can be implemented in conjunction with the additional techniques described in item 12 of the previous section.

[1001] 9. A method of video processing, comprising: determining based on a rule whether chroma blocks of a certain size are allowed in a video region of a video; and performing a conversion between the video region and a codec representation of the video region based on the determination.

[1002] 10. The method of clause 9, wherein the rule specifies that 2xN chroma blocks are prohibited because the video region includes a dual-tree partition.

[1003] 11. The method of clause 9, wherein the rule specifies that 2N chroma blocks are prohibited because the video region includes a single-tree partition.

[1004] 12. The method according to clause 10 or 11, wherein N≤64.

[1005] The following items can be implemented in conjunction with the additional techniques described in items 13, 14, and 15 of the previous sections.

[1006] 13. A method of video processing, comprising: determining a permissible codec mode for a video region based on a rule, the rule allowing use of the codec mode for a video condition; and performing conversion between a codec representation of pixels in the video region and pixels of the video region based on the determination.

[1007] 14. The method of clause 13, wherein the video condition is a block size, and wherein the rule allows use of intra block copy mode for small block size luma blocks.

[1008] 15. A method according to clause 14, wherein the small block size comprises an 8x4, 8x8, 16x4 or 4xN luma block size.

[1009] 16. The method of clause 13, wherein the rules allow use of intra block copy mode for conversion of the video region encoded or decoded using MODE_TYPE_INTER mode.

[1010] 17. The method of clause 13, wherein the rules allow conversion of the video region encoded using the MODE_TYPE_INTER mode to use a palette codec mode.

[1011] The following items can be implemented in conjunction with the additional techniques described in items 16, 17, and 18 of the previous sections.

[1012] 18. A method of video processing, comprising: performing conversion between video blocks of a video and a codec representation of the video blocks using a video codec mode, wherein syntax elements signaling the codec mode are selectively included in the codec representation based on a rule.

[1013] 19. A method according to clause 18, wherein the video codec mode is an intra-block codec mode, and wherein the rule specifies that the type of the video codec mode is used to control the inclusion of the syntax element in the codec representation.

[1014] 20. The method of clause 19, wherein the rules specify that non-SKIP blocks are explicitly signaled.

[1015] 21. The method of clause 18, wherein the rule specifies that an intra block copy flag is implicitly signaled based on a skip flag and a mode type of the video block.

[1016] 22. The method of clause 18, wherein the codec mode is a palette codec mode, and wherein the rule specifies selectively including a palette codec indicator based on a mode type of the video block.

[1017] The following items can be implemented in conjunction with the additional techniques described in item 21 of the previous section.

[1018] 23. A method for video processing, comprising: determining that a transform type used during a conversion between a chroma block and a coded representation of the chroma block is different from a transform type used for a corresponding luminance block conversion because the chroma block has a size less than a threshold size; and performing the conversion based on the determination.

[1019] 24. The method of clause 23, wherein the threshold size is MxN, where M is 2.

[1020] The following items can be implemented in conjunction with the additional techniques described in Item 22 of the previous section.

[1021] 25. A method according to any of clauses 1 to 24, wherein the converting uses a combined inter and intra prediction mode as MODE_TYPE_INTRA mode.

[1022] 26. A method according to any of clauses 18 to 22, wherein the conversion uses a combined inter- and intra-prediction mode as a MODE_TYPE_INTER mode. For example, when CIIP is considered as MODE_TYPE_INTER, the method described in items 14-17 of the previous section may be applied. Alternatively, when the method described in items 14-16 is applied, CIIP may be considered as MODE_TYPE_INTER.

[1023] The following items can be implemented in conjunction with the additional techniques described in items 3-6 of the previous section.

[1024] 27. A method of video processing, comprising: determining, based on a codec condition of a video region, whether to implement a minimum chroma block rule during a conversion between a codec representation of the video region and a pixel value of the video region; and performing the conversion based on the determination.

[1025] 28. The method of clause 17, wherein the codec condition comprises a color format of the video region.

[1026] 29. A method according to clause 18, wherein the video area has a width of M pixels and a height of N pixels, and wherein the encoding and decoding conditions also depend on the value of M and / or N.

[1027] 30. The method of clause 29, wherein the minimum chroma block rule is enabled because the video region has a 4:2:2 color format and M*N=32 or M*N=64.

[1028] The following items can be implemented in conjunction with the additional techniques described in items 7-11 of the previous section.

[1029] 31. A method for video processing, comprising: for conversion between a codec representation of a video area in a 4:2:2 format and a pixel value of the video area, determining a mode type to be used for the conversion based on whether a minimum chroma block rule is enabled for the video area; and performing the conversion based on the determination.

[1030] 32. A method according to clause 31, wherein the mode type of the video region is set to 1 because the video region has a 4:2:2 format and the minimum chroma block rule is enabled.

[1031] 33. The method of clause 31, wherein determining the mode type comprises determining the mode type as an INTRA type due to enabling the minimum chroma block rule for the video region.

[1032] 34. The method of clause 31, wherein determining the mode type comprises determining that the mode type INTER is disabled due to the minimum chroma block rule being enabled for the video region.

[1033] The following items can be implemented in conjunction with the additional techniques described in items 7-11 of the previous section.

[1034] 35. A method of video processing, comprising: for conversion between a codec representation of a video block and a video block of a video, determining whether block splitting is allowed during the conversion based on a mode type used during the conversion or a dimension of the video block; and using the determination to perform the conversion.

[1035] 36. The method of clause 35, wherein the block partitioning comprises binary tree partitioning or ternary tree partitioning.

[1036] 37. A method according to any of clauses 35-36, wherein if the mode type is INTER mode, the block segmentation is based on a restriction rule that allows or prohibits the segmentation type.

[1037] The following items can be implemented in conjunction with the additional techniques described in item 34 of the previous section.

[1038] 38. A method of video processing, comprising: for conversion between a codec representation of a video segment of a video and the video segment, determining to apply a special processing mode to a chroma block of size MxN, where M times N is an integer; and performing the conversion based on the determination.

[1039] 39. A method according to clause 38, wherein the special processing mode disables the use of chroma blocks during the conversion.

[1040] 40. The method of clause 38, wherein the special processing mode uses DC prediction for intra prediction of the chroma blocks.

[1041] 41. A method according to clause 38, wherein the special processing mode includes using a cross-component linear model to predict intra-frame coefficients of the chrominance block from corresponding downsampled luma coefficients.

[1042] 42. A method according to any of clauses 38-41, wherein the special processing mode disables the use of the chroma blocks due to the video segments using dual-tree partitioning.

[1043] 43. A method according to any of clauses 38-41, wherein the special processing mode disables the use of the chroma blocks due to the video segments using single-tree partitioning.

[1044] 44. A method according to any one of clauses 1 to 43, wherein the conversion comprises encoding the video into the codec representation.

[1045] 45. A method according to any one of clauses 1 to 43, wherein the conversion comprises decoding the codec representation to generate pixel values ​​of the video.

[1046] 46. ​​A video decoding apparatus comprising a processor configured to implement the method of one or more of clauses 1 to 45.

[1047] 47. A video encoding apparatus comprising a processor configured to implement the method of one or more of clauses 1 to 45.

[1048] 48. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method of any of clauses 1 to 45.

[1049] 49. The methods, apparatus, or systems described in this document.

[1050] The second set of items illustrates example embodiments of the techniques discussed in previous sections (eg, items 37-40).

[1051] 1. A method for video processing (e.g., Fig.24A The method 2400 shown includes: performing conversion 2402 between a video including a video region and a bitstream of the video according to a rule; and wherein the rule specifies the relationship between the enabling of a palette mode and a codec type of the video region.

[1052] 2. A method according to clause 1, wherein the rule specifies that the palette mode is enabled when the codec type is MODE_TYPE ALL which allows intra mode, palette mode and intra block copy mode for conversion, or MODE_TYPE_INTRA which allows intra mode for conversion.

[1053] 3. A method according to clause 2, wherein the rule specifies that the palette mode is always disabled if the codec type is MODE_TYPE_INTER which only allows inter-frame codec mode.

[1054] 4. A method of video processing (e.g., Fig. 24BThe method 2410 shown includes: performing a conversion 2412 between a video including a first video area and a second video area and a bitstream of the video according to a rule; and wherein the rule specifies that when the first block is in an intra-block copy mode and the second block is in a palette mode, the boundary strength (bs) of the deblocking filter of the chroma component of the video is set to 0.

[1055] 5. A method according to clause 4, wherein the rule further specifies that the boundary strength is set to 0 if a variable related to a chroma component in the video has a certain value.

[1056] 6. The method of clause 5, wherein the certain value is not equal to 0.

[1057] 7. A method of video processing (e.g., Fig.24C The method 2420 shown includes: performing conversion 2422 between a video and a bitstream of the video according to a format rule, and wherein the format rule specifies that variables related to the input bit depth of the video are constrained according to a summary table of the bitstream.

[1058] 8. The method of clause 7, wherein the variable is internal_minus_input_bit_depth.

[1059] 9. The method of clause 7, wherein the format rule specifies that, in the case of a 10-bit profile, the variable is constrained to be in the range [0, 2].

[1060] 10. The method of clause 7, wherein the format rule specifies that, in the case of an 8-bit profile, the variable is constrained to be 0.

[1061] 11. The method of clause 7, wherein the format rule specifies that, in the case of a (K+8)-bit profile, the variable is constrained to be in the range of [0, K], where K is an integer greater than 0.

[1062] 12. A method of video processing (e.g., Fig.24D The method 2430 shown includes: performing conversion 2432 between a video and a bitstream of the video according to a format rule, and wherein the format rule specifies that a variable indicating a minimum allowed quantization parameter is constrained according to a profile of the bitstream.

[1063] 13. The method of clause 12, wherein the variable is QpPrimeTsMin.

[1064] 14. A method according to clause 13, wherein the format rule specifies that, in the case of a 10-bit profile, (QpPrimeTsMin - 4) / 6 is constrained to be in the range [0, 2].

[1065] 15. A method according to clause 13, wherein the format rule specifies that, in the case of an 8-bit profile, (QpPrimeTsMin - 4) / 6 is constrained to be 0.

[1066] 16. The method of clause 12, wherein the format rule specifies that, in the case of a (K+8)-bit profile, (QpPrimeTsMin-4) / 6 is constrained to be in the range of [0, K], where K is an integer greater than 0.

[1067] 17. A method according to any one of clauses 1 to 16, wherein the converting comprises encoding the video into the bitstream.

[1068] 18. A method according to any of clauses 1 to 16, wherein the converting comprises decoding the video from the bitstream.

[1069] 19. The method of any one of clauses 1 to 16, wherein the converting comprises generating the bitstream from the video, and the method further comprises storing the bitstream in a non-transitory computer-readable recording medium.

[1070] 20. A video processing apparatus comprising a processor configured to implement the method according to any one or more of clauses 1 to 19.

[1071] 21. A method of storing a bitstream of a video, comprising the method according to any one of clauses 1 to 19, and further comprising storing the bitstream to a non-transitory computer-readable recording medium.

[1072] 22. A computer readable medium storing program code which, when executed, causes a processor to implement the method according to any one or more of clauses 1 to 19.

[1073] 23. A computer-readable medium storing a bitstream generated according to any one of the above methods.

[1074] 24. A video processing apparatus for storing a bitstream representation, wherein the video processing apparatus is configured to implement a method according to any one or more of clauses 1 to 19.

[1075] The disclosed and other solutions, examples, embodiments, modules and functional operations described in this document can be implemented in digital electronic circuits or in computer software, firmware or hardware (including the structures disclosed in this document and the equivalent of their structures), or in a combination of one or more thereof. The disclosed and other embodiments can be implemented as one or more computer program products, that is, one or more computer program instruction modules encoded on a computer-readable medium, for execution by a data processing device or controlling the operation of the data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a material component that affects a machine-readable propagable signal, or a combination of one or more thereof. The term "data processing device" covers all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. In addition to hardware, the device may also include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more thereof. A propagation signal is an artificially generated signal, such as a machine-generated electrical signal, an optical signal or an electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device.

[1076] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and the computer program can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that stores other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file storing a portion of one or more modules, subroutines, or codes). A computer program can be deployed to execute on one computer or on multiple computers, which are located at one site or distributed across multiple sites and interconnected by a communication network.

[1077] The processes and logic flows described in this document may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and the apparatus may be implemented as, a special purpose logic circuit such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[1078] Processors suitable for the execution of computer programs include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, the processor will receive instructions and data from a read-only memory or a random access memory or both. The necessary elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more large-capacity storage devices (such as magnetic, magneto-optical disks or optical disks) for storing data, or be operably coupled to receive data from one or more large-capacity storage devices (such as magnetic, magneto-optical disks or optical disks) or transfer data to one or more large-capacity storage devices (such as magnetic, magneto-optical disks or optical disks), or both. However, a computer does not need to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, such as semiconductor memory devices (such as EPROM, EEPROM and flash memory devices), disks (such as built-in hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks. Processors and memories can be supplemented by special logic circuits, or incorporated into special logic circuits.

[1079] Although this patent document contains many details, these details should not be interpreted as limitations on any subject matter or the scope of protection that can be claimed, but as descriptions of the features of specific embodiments of specific technologies. In this patent document, certain features described in the context of separate embodiments can also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments respectively or in various suitable sub-combinations. In addition, although the features can be described as working in certain combinations as described above and even initially required, one or more features from the claimed combination can be removed from the combination in some cases, and the claimed combination can be directed to a variation of a sub-combination or a sub-combination.

[1080] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in the sequential order shown, or that all of the operations shown be performed, in order to achieve the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[1081] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and illustrated in this patent document.

Claims

1. A method for processing video data, comprising: For a conversion between a current video block of a video picture of a video and a bitstream of the video, determining whether a first codec mode is applied to the current video block according to a first rule, wherein in the first codec mode, reconstructed samples are represented by a representative color value set, and the representative color value set includes at least one of 1) a palette prediction value or 2) an escape sample included in the bitstream; as well as performing said converting based at least on said determining, wherein the first rule specifies that when the current video block has a mode type MODE_TYPE_ALL or a mode type MODE_TYPE_INTRA, the first codec mode is conditionally allowed for the current video block, and when the current video block has a mode type MODE_TYPE_INTER, the first codec mode is not allowed for the current video block, wherein a reconstructed picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a second rule, wherein the second rule specifies that when a condition set is not satisfied, the reconstructed picture sample array is a reconstructed luminance picture sample array, a variable associated with an edge flag is not equal to 2, and two variables mapped to two samples have different values, bS[xDi][yDj] is equal to 0, Wherein, bS[xDi][yDj] represents an element in an array of the boundary filter strength for xDi and yDj, where i = 0...xN, j = 0...yN, The two samples are samples of the reconstructed picture sample array corresponding to bS[xDi][yDj], The two variables respectively indicate prediction modes of two video blocks in the reconstructed picture sample array and including the two samples, or the two variables respectively indicate prediction modes of two video sub-blocks divided from one or more video blocks in the reconstructed picture sample array and including the two samples.

2. The method according to claim 1, wherein: The mode type MODE_TYPE_ALL specifies whether intra mode, intra block copy mode, first codec mode and inter mode are allowed for the video blocks in the codec tree node including the current video block, The mode type MODE_TYPE_INTRA specifies whether only the intra mode, the intra block copy mode, and the first codec mode are allowed to be used for the video blocks in the codec tree node including the current video block, and The mode type MODE_TYPE_INTER specifies whether only the inter-frame mode is allowed to be used for the video blocks in the codec tree node including the current video block.

3. The method according to claim 1, wherein: The second rule further specifies that when the condition set is not satisfied, the reconstructed picture sample array is a reconstructed chroma picture sample array, and the two variables mapped to the two samples have different values, bS[xDi][yDj] is equal to 0.

4. The method according to claim 1, wherein: The condition set includes that the two samples are in a video block with ciip_flag equal to 1.

5. The method according to claim 1, wherein: The condition set includes that the prediction mode of the first sample located in the same video unit as one of the two samples is an intra mode.

6. The method according to claim 1, wherein: A reconstructed chroma picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed chroma picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a third rule, wherein the third rule specifies that when two samples of the reconstructed chroma picture sample array are located on both sides of an edge and the two sides are encoded and decoded in the first encoding and decoding mode and the intra block copy mode, respectively, bS[xDi][yDj] corresponding to the two samples are set to be equal to 0.

7. The method according to claim 1, wherein: A syntax element indicating the bit depth of samples in the video picture is included in the bitstream and is constrained to be within [0, M] in a (M+8)-bit profile, where M is a positive integer.

8. The method according to claim 1, wherein: The converting includes encoding the video into the bitstream.

9. The method according to claim 1, wherein: The converting includes decoding the video from the bitstream.

10. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to: For conversion between a current video block of a video picture of a video and a bitstream of the video, determining whether a first codec mode is applied to the current video block according to a first rule, wherein in the first codec mode, reconstructed samples are represented by a representative color value set, and the representative color value set includes at least one of 1) a palette prediction value or 2) an escape sample included in the bitstream; and performing said converting based at least on said determining, in, The first rule specifies that when the current video block has a mode type MODE_TYPE_ALL or a mode type MODE_TYPE_INTRA, the first codec mode is conditionally allowed for the current video block, and when the current video block has a mode type MODE_TYPE_INTER, the first codec mode is not allowed for the current video block, wherein a reconstructed picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a second rule, wherein the second rule specifies that when a condition set is not satisfied, the reconstructed picture sample array is a reconstructed luminance picture sample array, a variable associated with an edge flag is not equal to 2, and two variables mapped to two samples have different values, bS[xDi][yDj] is equal to 0, Wherein, bS[xDi][yDj] represents an element in an array of the boundary filter strength for xDi and yDj, where i = 0...xN, j = 0...yN, The two samples are samples of the reconstructed picture sample array corresponding to bS[xDi][yDj], The two variables respectively indicate prediction modes of two video blocks in the reconstructed picture sample array and including the two samples, or the two variables respectively indicate prediction modes of two video sub-blocks divided from one or more video blocks in the reconstructed picture sample array and including the two samples.

11. The device according to claim 10, wherein: The mode type MODE_TYPE_ALL specifies whether intra mode, intra block copy mode, first codec mode and inter mode are allowed for the video blocks in the codec tree node including the current video block, The mode type MODE_TYPE_INTRA specifies whether only the intra mode, the intra block copy mode, and the first codec mode are allowed to be used for the video blocks in the codec tree node including the current video block, and The mode type MODE_TYPE_INTER specifies whether only the inter-frame mode is allowed to be used for the video blocks in the codec tree node including the current video block.

12. The device according to claim 10, wherein: The second rule further specifies that when the condition set is not satisfied, the reconstructed picture sample array is a reconstructed chroma picture sample array, and the two variables mapped to the two samples have different values, bS[xDi][yDj] is equal to 0.

13. The device according to claim 10, wherein: The condition set includes that the two samples are in a video block with ciip_flag equal to 1.

14. The device according to claim 10, wherein: The condition set includes that the prediction mode of the first sample located in the same video unit as one of the two samples is an intra mode.

15. A non-transitory computer-readable storage medium storing instructions that cause a processor to: For conversion between a current video block of a video picture of a video and a bitstream of the video, determining whether a first codec mode is applied to the current video block according to a first rule, wherein in the first codec mode, reconstructed samples are represented by a representative color value set, and the representative color value set includes at least one of 1) a palette prediction value or 2) an escape sample included in the bitstream; and performing said converting based at least on said determining, in, The first rule specifies that when the current video block has a mode type MODE_TYPE_ALL or MODE_TYPE_INTRA, the first codec mode is conditionally allowed for the current video block, and when the current video block has a mode type MODE_TYPE_INTER, the first codec mode is not allowed for the current video block wherein a reconstructed picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a second rule, wherein the second rule specifies that when a condition set is not satisfied, the reconstructed picture sample array is a reconstructed luminance picture sample array, a variable associated with an edge flag is not equal to 2, and two variables mapped to two samples have different values, bS[xDi][yDj] is equal to 0, Wherein, bS[xDi][yDj] represents an element in an array of the boundary filter strength for xDi and yDj, where i = 0...xN, j = 0...yN, The two samples are samples of the reconstructed picture sample array corresponding to bS[xDi][yDj], The two variables respectively indicate prediction modes of two video blocks in the reconstructed picture sample array and including the two samples, or the two variables respectively indicate prediction modes of two video sub-blocks divided from one or more video blocks in the reconstructed picture sample array and including the two samples.

16. The storage medium according to claim 15, wherein: The mode type MODE_TYPE_ALL specifies whether intra mode, intra block copy mode, first codec mode and inter mode are allowed for the video blocks in the codec tree node including the current video block, The mode type MODE_TYPE_INTRA specifies whether only the intra mode, the intra block copy mode, and the first codec mode are allowed to be used for the video blocks in the codec tree node including the current video block, and The mode type MODE_TYPE_INTER specifies whether only the inter-frame mode is allowed to be used for the video blocks in the codec tree node including the current video block.

17. The storage medium according to claim 15, wherein: The condition set includes that the two samples are in a video block with ciip_flag equal to 1.

18. The storage medium according to claim 15, wherein: The condition set includes that the prediction mode of the first sample located in the same video unit as one of the two samples is an intra mode.

19. A non-transitory computer-readable recording medium storing a bit stream generated by a method performed by a video processing device, wherein the method comprises: For a current video block of a video picture of a video, determining, according to a first rule, whether a first coding mode is applied to the current video block, wherein in the first coding mode, reconstructed samples are represented by a representative color value set, and the representative color value set includes at least one of 1) a palette prediction value or 2) an escape sample included in the bitstream; as well as generating the bitstream based at least on the determining, wherein the first rule specifies that, when the current video block has a mode type MODE_TYPE_ALL or MODE_TYPE_INTRA, the first codec mode is conditionally allowed for the current video block, and when the current video block has a mode type MODE_TYPE_INTER, the first codec mode is not allowed for the current video block, wherein a reconstructed picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a second rule, wherein the second rule specifies that when a condition set is not satisfied, the reconstructed picture sample array is a reconstructed luminance picture sample array, a variable associated with an edge flag is not equal to 2, and two variables mapped to two samples have different values, bS[xDi][yDj] is equal to 0, Wherein, bS[xDi][yDj] represents an element in an array of the boundary filter strength for xDi and yDj, where i = 0...xN, j = 0...yN, The two samples are samples of the reconstructed picture sample array corresponding to bS[xDi][yDj], The two variables respectively indicate prediction modes of two video blocks in the reconstructed picture sample array and including the two samples, or the two variables respectively indicate prediction modes of two video sub-blocks divided from one or more video blocks in the reconstructed picture sample array and including the two samples.

20. A method for storing a bitstream of a video, comprising: For a current video block of a video picture of the video, determining, according to a first rule, whether a first coding mode is applied to the current video block, wherein in the first coding mode, a reconstructed sample is represented by a representative color value set, and the representative color value set includes at least one of 1) a palette prediction value or 2) an escape sample or the like included in the bitstream; generating the bitstream based at least on the determining; as well as storing the bitstream in a non-transitory computer-readable recording medium, wherein the first rule specifies that, when the current video block has a mode type MODE_TYPE_ALL or MODE_TYPE_INTRA, the first codec mode is conditionally allowed for the current video block, and when the current video block has a mode type MODE_TYPE_INTER, the first codec mode is not allowed for the current video block, wherein a reconstructed picture sample array of the video picture is further obtained, and a deblocking filtering process is applied to at least one edge in the reconstructed picture sample array, wherein an array of boundary filter strengths is derived for the deblocking filtering process according to a second rule, wherein the second rule specifies that when a condition set is not satisfied, the reconstructed picture sample array is a reconstructed luminance picture sample array, a variable associated with an edge flag is not equal to 2, and two variables mapped to two samples have different values, bS[xDi][yDj] is equal to 0, Wherein, bS[xDi][yDj] represents an element in an array of the boundary filter strength for xDi and yDj, where i = 0...xN, j = 0...yN, The two samples are samples of the reconstructed picture sample array corresponding to bS[xDi][yDj], The two variables respectively indicate prediction modes of two video blocks in the reconstructed picture sample array and including the two samples, or the two variables respectively indicate prediction modes of two video sub-blocks divided from one or more video blocks in the reconstructed picture sample array and including the two samples.

Images