Deblocking parameters for chroma components

Abstract

Video processing methods, systems, and apparatuses are described. An example method includes performing a conversion between a block of a video and a bitstream of the video according to a rule. The rule specifies that whether a syntax element identifying a deblocking offset for a chroma component of the video is included in a video region level is determined based on a color format of the video.

Description

[0001] Cross-references to related applications

[0002] Pursuant to the applicable Patent Law and / or the Paris Convention, this application claims priority and interest in International Patent Application PCT / CN2020 / 074316, filed on February 5, 2020. For all legal purposes, the entire disclosure of the foregoing application is incorporated herein by reference as a part of this application disclosure. Technical Field

[0003] This patent document relates to image and video encoding and decoding technologies. Background Technology

[0004] Digital video consumes the largest share of bandwidth in the internet and other digital communication networks. As the number of connected user devices capable of receiving and displaying video increases, the bandwidth demand for digital video is expected to continue to grow. Summary of the Invention

[0005] This document discloses techniques that can be used by video encoders and decoders for video processing using a palette mode, in which a palette representing sample values ​​is used to represent the video.

[0006] In one example aspect, a video processing method is disclosed. The method includes performing a conversion between video blocks and the video bitstream according to rules, wherein the rules specify whether a syntax element identifying the deblocking offset of the video's chroma components is included at the video region level based on the video's color format.

[0007] In another example, a video processing method is disclosed. This method includes performing a conversion between video blocks and a video bitstream according to rules, wherein the rules specify whether a syntax element identifying the deblocking offset of the video's chroma components is included at the video region level, based on syntax flags indicating whether an encoding / decoding tool for processing different color components individually is enabled.

[0008] In another example, a video processing method is disclosed. This method includes performing a conversion between video blocks and the video bitstream according to rules, wherein the rules specify whether a syntax element identifying the deblocking offset of the video's chroma components is included at the video region level, based on syntax flags specifying the presence of parameters for encoding / decoding tools for chroma components in the bitstream.

[0009] In another example, a video processing method is disclosed. This method includes performing a conversion between blocks of video and the bitstream of the video according to rules, wherein the rules specify syntax flags indicating whether chroma quantization parameter offsets are processed for the conversion, and also indicate whether deblocking offsets of the video's chroma components exist or are processed for the conversion.

[0010] In another example, a video processing method is disclosed. The method includes performing a conversion between video blocks and a codec representation of the video, wherein a palette pattern is used in the codec representation of the video blocks, wherein a palette of representative color values ​​is used to represent samples of the video blocks; and wherein samples outside the palette are encoded and decoded using an escape character and values ​​quantized using quantization parameters within a range of minimum and maximum permissible values ​​determined by rules.

[0011] In another example, a video processing method is disclosed. The method includes performing a conversion between video blocks and a codec representation of the video, wherein a palette pattern is used in the codec representation of the video blocks, wherein a palette of representative color values ​​is used to represent samples of the video blocks; and wherein the size of the palette depends on a rule regarding whether a local bitree is used for the conversion between the video blocks and the codec representation.

[0012] In another example, a video processing method is disclosed. The method includes performing a conversion between video blocks and a codec representation of the video, wherein a palette pattern is used in the codec representation of the video blocks, wherein a palette of representative color values ​​is used to represent samples of the video blocks; and wherein the size of the palette predictor depends on a rule regarding whether a local dual tree is used for the conversion between the video blocks and the codec representation.

[0013] In another example, a video processing method is disclosed. The method includes, for a conversion between a video block of a video region and the codec representation of the video, determining, based on codec conditions, whether a syntax element identifying a deblocking offset of the video's chroma components is included in the codec representation at the video region level; and performing the conversion based on this determination; wherein the deblocking offset is used to selectively enable deblocking operations on the video block.

[0014] In another example, a video processing method is disclosed. The method includes, for a video region of a video, a conversion between a video block and the codec representation of the video; determining, based on codec conditions, whether a syntax element indicating the use of a chroma codec tool is included in the codec representation at the video region level; and performing the conversion based on that determination; wherein a deblocking offset is used to selectively enable deblocking operations on the video block.

[0015] In another example, a video processing method is disclosed. The method includes performing a conversion between video blocks of video regions of a video and a codec representation of the video, wherein the codec representation conforms to a format; wherein the format specifies whether a first flag indicating a deblocking offset of the chroma components of the video is included in the codec representation, based on whether a second flag indicating a quantization parameter offset of the chroma components is included in the codec representation.

[0016] In another example, a video processing method is disclosed. The method includes performing a conversion between video blocks of a video region and a codec representation of the video, wherein the codec representation conforms to a format rule; wherein the format rule specifies whether one or more parameters in the codec representation, which indicate the applicability of one or more chroma codec tools, are included in the codec representation at the video region or video block level.

[0017] In yet another example, a video encoder apparatus is disclosed. This video encoder includes a processor configured to implement the methods described above.

[0018] In yet another example, a video decoder apparatus is disclosed. This video decoder includes a processor configured to implement the methods described above.

[0019] In yet another example, a computer-readable medium on which code is stored is disclosed. This code implements one of the methods described herein in the form of processor-executable code.

[0020] These and other features will be described in this document. Attached Figure Description

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

[0022] Figure 2 The illustration shows the use of a palette predictor to signal palette entries.

[0023] Figure 3 Examples of horizontal and vertical traversal scans are shown.

[0024] Figure 4 The illustration shows an example encoding / decoding of the palette index.

[0025] Figure 5A An example of the Minimum Chromaticity Inter-Frame Prediction Unit (SCIPU) is shown.

[0026] Figure 5B Another example of the Minimum Chromaticity Inter-Frame Prediction Unit (SCIPU) is shown.

[0027] Figure 6 This is a schematic diagram of the decoding process using ACT.

[0028] Figure 7 This is a block diagram of an example video processing system.

[0029] Figure 8 This is a block diagram of a video processing device.

[0030] Figure 9 This is a flowchart of an example method for video processing.

[0031] Figure 10 This is a block diagram illustrating a video encoding / decoding system according to some embodiments of the present disclosure.

[0032] Figure 11 This is a block diagram illustrating an encoder according to some embodiments of the present disclosure.

[0033] Figure 12 This is a block diagram illustrating a decoder according to some embodiments of the present disclosure.

[0034] Figure 13 This is a flowchart representation of the video processing method based on this technology.

[0035] Figure 14 This is a flowchart representation of another video processing method based on this technology.

[0036] Figure 15 This is a flowchart representation of another video processing method based on this technology.

[0037] Figure 16 This is a flowchart representation of another video processing method based on this technology. Detailed Implementation

[0038] The use of section headers in this document is for ease of understanding and not to limit the applicability of the technologies and embodiments disclosed in each section to that section only. Furthermore, the use of H.266 terminology in some descriptions is merely for ease of understanding and not to limit the scope of the disclosed technologies. Therefore, the technologies described herein are also applicable to other video codec protocols and designs.

[0039] 1. Overview

[0040] This document relates to video codec technology. Specifically, it covers indexed and escape symbol encoding / decoding in palette encoding / decoding, as well as chroma format signaling notification. It can be applied to existing video codec standards, such as HEVC, or upcoming standards (Multi-Functional Video Codec). It can also be applied to future video codec standards or video codecs.

[0041] 2. Video codec standards

[0042] Video codec standards have primarily evolved through the development of well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, while ISO / IEC developed MPEG-1 and MPEG-4 Visual. These two organizations jointly developed the H.262 / MPEG-2 video and H.264 / MPEG-4 Advanced Video Coding (AVC) and H.265 / HEVC standards. Since H.262, video codec standards have been based on hybrid video codec architectures, utilizing temporal prediction plus transform coding. To explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted many new methods and incorporated them into reference software called the Joint Exploration Model (JEM). In April 2018, VCEG (Q6 / 16) and ISO / IEC JTC1SC29 / WG11 (MPEG) established the Joint Video Experts Group (JVET), which is dedicated to the VVC standard with the goal of reducing the bit rate by 50% compared to HEVC.

[0043] 2.1 Palette Mode in HEVC Screen Content Codec Extension (HEVC-SCC)

[0044] 2.1.1 The concept of palette mode

[0045] The basic idea behind palette mode is that pixels in a CU are represented by a small, representative set of color values. This set is called the palette. Samples outside the palette can be indicated by signaling followed by an escape term for (potentially quantized) component values. These pixels are called escape pixels. Palette mode is as follows: Figure 1 As shown. Figure 1 As shown, for each pixel with three color components (luminance and two chrominance components), an index of the color palette is established, and the block can be reconstructed based on the values ​​established in the color palette.

[0046] 2.1.2 Encoding and Decoding of Palette Entries

[0047] For encoding and decoding of palette entries, a palette predictor is maintained. The maximum size of the palette and palette predictor is communicated via signaling in the SPS. In HEVC-SCC, the `palette_predictor_initializer_present_flag` is introduced in the PPS. When this flag is 1, the entry used to initialize the palette predictor is communicated via signaling in the bitstream. The palette predictor is initialized at the beginning of each CTU line, each stripe, and each slice. Depending on the value of `palette_predictor_initializer_present_flag`, the palette predictor is either reset to 0 or initialized using the palette predictor initializer entry communicated via signaling in the PPS. In HEVC-SCC, a palette predictor initializer of size 0 is enabled to allow explicit disabling of palette predictor initialization at the PPS level.

[0048] For each entry in the palette predictor, a signaling notification reuse flag is used to indicate whether it is part of the current palette. This is in Figure 2 The diagram shows the process. A zero-run-length encoding / decoding method is used to deliver the reuse flag. Subsequently, a zero-order exponent Golomb (EG) code, i.e., EG-0, is used to signal the number of new palette entries. Finally, the component values ​​of the new palette entries are signaled.

[0049] 2.1.3 Palette Index Encoding and Decoding

[0050] like Figure 3 As shown, the palette index is encoded using both horizontal and vertical traversal scans. The scan order is explicitly signaled in the bitstream using the `palette_transpose_flag`. For the remainder of this section, it is assumed that the scan is horizontal.

[0051] The palette index is encoded and decoded using two palette sample modes: "COPY_LEFT" and "COPY_ABOVE". In "COPY_LEFT" mode, the palette index is assigned to the decoding index. In "COPY_ABOVE" mode, the palette index of the sample in the previous row is copied. For both "COPY_LEFT" and "COPY_ABOVE" modes, the signaling notification specifies the number of run values ​​for subsequent samples that are also encoded and decoded using the same mode.

[0052] In palette mode, the index value of the escape symbol is the number of palette entries. Furthermore, when the escape symbol is part of a downstream process in "COPY_LEFT" or "COPY_ABOVE" mode, the escape component value is signaled for each escape symbol. The encoding and decoding of the palette index is as follows... Figure 4 As shown.

[0053] This grammatical sequence is performed as follows: First, the signaling informs the number of index values ​​for the CU. Next, truncated binary encoding / decoding is used to signal the actual index values ​​for the entire CU. Both the index count and index values ​​are encoded / decoded in bypass mode. This groups the bypass binary numbers associated with the indexes together. Then, the palette sample mode (if necessary) and run lengths are signaled in an interleaved manner. Finally, the component escape values ​​corresponding to the escape samples of the entire CU are grouped together and encoded / decoded in bypass mode. The binaryization of the escape samples is EG encoding with third order, i.e., EG-3.

[0054] The additional syntax element `last_run_type_flag` is signaled after the index value. This syntax element, combined with the number of indices, eliminates the need for signaling the run value corresponding to the last run in the block.

[0055] In HEVC-SCC, the palette mode also supports 4:2:2, 4:2:0, and monochrome chroma formats. For all chroma formats, the signaling notifications for palette entries and palette indices are almost identical. In non-monochrome formats, each palette entry consists of 3 components. In monochrome formats, each palette entry consists of one component. For subsampled chroma directions, chroma samples are associated with a luminance sample index divisible by 2. After reconstructing the palette index for the CU, if a sample has only one associated component, only the first component of the palette entry is used. The only difference in signaling notifications is the number of escaped component values. For each escaped symbol, the number of escaped component values ​​in the signaling notification may differ depending on the number of components associated with that symbol.

[0056] Figure 4 The illustration shows an example encoding / decoding of the palette index.

[0057] Furthermore, the palette index encoding and decoding process includes an index adjustment procedure. When signaling is sent to the palette index, the left adjacent index or the upper adjacent index should be different from the current index. Therefore, by eliminating one possibility, the range of the current palette index can be reduced by 1. Afterwards, the index is signaled using truncated binary (TB) binary representation.

[0058] The relevant text for this section is shown below, where CurrPaletteIndex is the current palette index and adjustedRefPaletteIndex is the predicted index.

[0059] The variable PaletteIndexMap[xC][yC] specifies the palette index, which is the index of an array represented by CurrentPaletteEntries. The array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left brightness sample of the image. The value of PaletteIndexMap[xC][yC] should be in the range of 0 to MaxPaletteIndex, inclusive.

[0060] The derivation of the variable adjustedRefPaletteIndex is as follows:

[0061]

[0062] When CopyAboveIndicesFlag[xC][yC] equals 0, the derivation of the variable CurrPaletteIndex is as follows:

[0063] if(CurrPaletteIndex>=adjustedRefPaletteIndex)

[0064] CurrPaletteIndex++

[0065] Furthermore, the run-length element in the palette pattern is context-coded. The relevant context derivation process described in JVET-O2011-vE is shown below.

[0066] Derivation of ctxInc for the syntax element palette_run_prefix

[0067] The input to this process is the binary index binIdx and the syntax elements copy_above_palette_indexes_flag and palette_idx_idc.

[0068] The output of this process is the variable ctxInc.

[0069] The derivation of the variable ctxInc is as follows:

[0070] – If copy_above_palette_indexes_flag equals 0 and binIdx equals 0.

[0071] The derivation of ctxInc is as follows:

[0072] ctxInc=(palette_idx_idc<1)? 0:((palette_idx_idc<3)?1:2) (9-69)

[0073] – Otherwise, ctxInc is provided by Table 1:

[0074] Table 1 – Specification of ctxIdxMap[copy_above_palette_indices_flag][binIdx]

[0075]

[0076] 2.2 Palette Mode in VCC

[0077] 2.2.1 Palette in Two Trees

[0078] In VVC, a dual-tree codec structure is used to encode and decode intra-frame stripes, allowing the luma component and the two chroma components to have different palettes and palette indices. Furthermore, the two chroma components share the same palette and palette index.

[0079] 2.2.2 Palette as a Separation Mode

[0080] In some embodiments, the prediction mode used for the codec unit can be MODE_INTRA, MODE_INTER, MODE_IBC, and MODE_PLT. The binary representation of the prediction mode changes accordingly.

[0081] When IBC is disabled, for I-slices, the first binary number is used to indicate whether the current prediction mode is MODE_PLT. For P / B-slices, the first binary number is used to indicate whether the current prediction mode is MODE_INTRA. If not, an additional binary number is used to indicate whether the current prediction mode is MODE_PLT or MODE_INTER.

[0082] When IBC is enabled, for I-frames, the first binary number is used to indicate whether the current prediction mode is MODE_IBC. If not, the second binary number is used to indicate whether the current prediction mode is MODE_PLT or MODE_INTRA. For P / B-frames, the first binary number is used to indicate whether the current prediction mode is MODE_INTRA. If it is an intra-frame mode, the second binary number is used to indicate whether the current prediction mode is MODE_PLT or MODE_INTRA. If not, the second binary number is used to indicate whether the current prediction mode is MODE_IBC or MODE_INTER.

[0083] Example text is shown below.

[0084]

[0085]

[0086] 2.2.3 Palette Mode Syntax

[0087]

[0088]

[0089]

[0090]

[0091]

[0092]

[0093] 2.2.4 Palette Mode Semantics

[0094] In the following semantics, array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the codec block under consideration relative to the top-left luminance sample of the image. Array indices xC and yC specify the position (xC, yC) of this sample relative to the top-left luminance sample of the image. The array index startComp specifies the first color component of the current palette table. startComp equals 0 for the Y component; startComp equals 1 for the Cb component; and startComp equals 2 for the Cr component. numComps specifies the number of color components in the current palette table.

[0095] The predictor palette includes palette entries from previous encoding / decoding units used to predict entries in the current palette.

[0096] The variable PredictorPaletteSize[startComp] specifies the size of the predictor palette for the first color component startComp of the current palette table. PredictorPaletteSize is derived according to the provisions in Clause 8.4.5.3.

[0097] The variable `PalettePredictorEntryReuseFlags[i]` being equal to 1 indicates that the i-th entry in the predictor palette is reused in the current palette. `PalettePredictorEntryReuseFlags[i]` being equal to 0 indicates that the i-th entry in the predictor palette is not an entry in the current palette. All elements of the array `PalettePredictorEntryReuseFlags[i]` are initialized to 0.

[0098] The `palette_predictor_run` function determines the number of zeros preceding non-zero entries in the array `PalettePredictorEntryReuseFlags`.

[0099] The requirement for bitstream consistency is that the value of `palette_predictor_run` should be in the range of 0 to (`PredictorPaletteSize - predictorEntryIdx`), inclusive, where `predictorEntryIdx` corresponds to the current position in the array `PalettePredictorEntryReuseFlags`. The variable `NumPredictedPaletteEntries` specifies the number of entries reused from the predictor palette in the current palette. The value of `NumPredictedPaletteEntries` should be in the range of 0 to `palette_max_size`, inclusive.

[0100] num_signalled_palette_entries specifies the number of entries in the current palette that explicitly signal the first color component of the current palette table, startComp.

[0101] When num_signalled_palette_entries does not exist, it is inferred to be equal to 0.

[0102] The variable CurrentPaletteSize[startComp] specifies the size of the current palette for the first color component startComp of the current palette table, and is deduced as follows:

[0103] CurrentPaletteSize[startComp]=NumPredictedPaletteEntries+num_signalled_palette_entries (7-155)

[0104] The value of CurrentPaletteSize[startComp] should be in the range of 0 to palette_max_size, inclusive.

[0105] new_palette_entries[cIdx][i] specifies the value of the palette entry used for the i-th signaling notification of color component cIdx.

[0106] The variable PredictorPaletteEntries[cIdx][i] specifies the i-th element in the predictor palette used for color component cIdx.

[0107] The variable CurrentPaletteEntries[cIdx][i] specifies the i-th element in the current palette used for color component cIdx, and is deduced as follows:

[0108]

[0109] A `palette_escape_val_present_flag` value of 1 indicates that the current codec unit contains at least one escaped codec sample. A `escape_val_present_flag` value of 0 indicates that there are no escaped codec samples in the current codec unit. When it does not exist, the value of `palette_escape_val_present_flag` is inferred to be 1.

[0110] The variable MaxPaletteIndex specifies the maximum possible value of the palette index for the current codec unit. The value of MaxPaletteIndex is set to equal CurrentPaletteSize[startComp]-1+palette_escape_val_present_flag.

[0111] num_palette_indices_minus1 plus 1 is the number of palette indices for explicit signaling notification or inference for the current block.

[0112] When num_palette_indices_minus1 does not exist, it is inferred to be equal to 0.

[0113] palette_idx_idc is an indicator of the index CurrentPaletteEntries in the palette table. For the first index in the block, the value of palette_idx_idc should be in the range of 0 to MaxPaletteIndex, inclusive. For the remaining indices in the block, the value of palette_idx_idc should be in the range of 0 to MaxPaletteIndex-1, inclusive.

[0114] When palette_idx_idc does not exist, it is inferred to be equal to 0.

[0115] The variable PaletteIndexIdc[i] stores the i-th palette_idx_idc of explicit signaling notifications or inferences. All elements of the array PaletteIndexIdc[i] are initialized to 0.

[0116] `copy_above_indices_for_final_run_flag` equal to 1 specifies that if a horizontal traversal scan is used, the palette index of the last position in the codec unit is copied from the palette index in the previous row; or if a vertical traversal scan is used, it is copied from the palette index in the left column. `copy_above_indices_for_final_run_flag` equal to 0 specifies that the palette index of the last position in the codec unit is copied from `PaletteIndexIdc[num_palette_indices_minus1]`.

[0117] When copy_above_indices_for_final_run_flag does not exist, it is inferred to be equal to 0.

[0118] A palette_transpose_flag value of 1 specifies that a vertical traversal scan is applied to scan the indices of the samples in the current codec unit. A palette_transpose_flag value of 0 specifies that a horizontal traversal scan is applied to scan the indices of the samples in the current codec unit. When it does not exist, the value of palette_transpose_flag is inferred to be 0.

[0119] The array TraverseScanOrder specifies the scan order array for the palette encoding and decoding. If palette_transpose_flag equals 0, TraverseScanOrder is assigned the horizontal scan order HorTravScanOrder, and if palette_transpose_flag equals 1, TraverseScanOrder is assigned the vertical scan order VerTravScanOrder.

[0120] `copy_above_palette_indices_flag` equal to 1 specifies that if a horizontal traversal scan is used, the palette index is equal to the palette index at the same position in the previous row; or if a vertical traversal scan is used, the palette index is equal to the palette index at the same position in the left column. `copy_above_palette_indices_flag` equal to 0 specifies that the palette index of the sample is either encoded / decoded or inferred in the bitstream.

[0121] The variable `CopyAboveIndicesFlag[xC][yC]` equal to 1 specifies that the palette index is copied from the palette index in the previous row (horizontal scan) or the left column (vertical scan). `CopyAboveIndicesFlag[xC][yC]` equal to 0 specifies that the palette index is explicitly encoded / decoded or inferred in the bitstream. The array indices `xC` and `yC` specify the position (xC, yC) of the sample relative to the top-left luminance sample of the image. The value of `PaletteIndexMap[xC][yC]` should be in the range of 0 to (`MaxPaletteIndex – 1`), inclusive.

[0122] The variable PaletteIndexMap[xC][yC] specifies the palette index, which is the index of an array represented by CurrentPaletteEntries. The array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left brightness sample of the image. The value of PaletteIndexMap[xC][yC] should be in the range of 0 to MaxPaletteIndex, inclusive.

[0123] The variable adjustedRefPaletteIndex is derived as follows:

[0124]

[0125] When CopyAboveIndicesFlag[xC][yC] equals 0, the variable CurrPaletteIndex is deduced as follows:

[0126] if(CurrPaletteIndex>=adjustedRefPaletteIndex)

[0127] CurrPaletteIndex++ (7-158)

[0128] palette_run_prefix, if present, specifies the prefix portion in the binary representation of PaletteRunMinus1.

[0129] `palette_run_suffix` is used to deduce the value of the variable `PaletteRunMinus1`. When it does not exist, the value of `palette_run_suffix` is deduced to be 0.

[0130] When RunToEnd equals 0, the variable PaletteRunMinus1 is derived as follows:

[0131] – If PaletteMaxRunMinus1 equals 0, then PaletteRunMinus1 is set to equal to 0.

[0132] - Otherwise (PaletteMaxRunMinus1 is greater than 0), the following applies:

[0133] – If palette_run_prefix is ​​less than 2, the following applies:

[0134] PaletteRunMinus1=palette_run_prefix (7-159)

[0135] – Otherwise (palette_run_prefix is ​​greater than or equal to 2), the following applies:

[0136] PrefixOffset=1<<(palette_run_prefix-1)

[0137] PaletteRunMinus1=PrefixOffset+palette_run_suffix (7-160)

[0138] The variable PaletteRunMinus1 is used as follows:

[0139] – If CopyAboveIndicesFlag[xC][yC] equals 0, then PaletteRunMinus1 specifies the number of consecutive positions with the same palette index minus 1.

[0140] Otherwise, if palette_transpose_flag equals 0, PaletteRunMinus1 specifies the number of consecutive positions with the same palette index used in the corresponding position in the previous row minus 1.

[0141] – Otherwise, PaletteRunMinus1 specifies the number of consecutive positions where the palette index is the same as the palette index used in the corresponding position in the left column minus 1.

[0142] When RunToEnd equals 0, the variable PaletteMaxRunMinus1 represents the maximum possible value of PaletteMaxRunMinus1, and the requirement for bitstream consistency is that the value of PaletteMaxRunMinus1 should be greater than or equal to 0.

[0143] Palette_escape_val specifies the quantization escape codec sample value for a component.

[0144] The variable `PaletteEscapeVal[cIdx][xC][yC]` specifies the escape value of the sample, where `PaletteIndexMap[xC][yC]` equals `MaxPaletteIndex`, and `palette_escape_val_present_flag` equals 1. The array index `cIdx` specifies the color component. The array indices `xC` and `yC` specify the position (xC, yC) of the sample relative to the top-left luminance sample of the image.

[0145] The requirement for bitstream consistency is that, for cIdx equal to 0, PaletteEscapeVal[cIdx][xC][yC] should be between 0 and (1 << (BitDepth)). Y The range is +1))-1, including the endpoint. For cIdx not equal to 0, then it is within the range of 0 to (1<<(BitDepth)). C The range is +1))-1, including the endpoints.

[0146] 2.2.5 Line-based CG Palette Mode

[0147] VVC employs a line-based CG palette pattern. In this method, each CU in the palette pattern is divided into multiple segments containing m samples (m = 16 in this test) based on the traversal scan pattern. The encoding order of the palette run-length encoding / decoding within each segment is as follows: For each pixel, a signaling instruction is given with a context-coded binary number `run_copy_flag = 0`, indicating whether the pixel has the same pattern as the previous pixel; that is, whether both the previous scanned pixel and the current pixel are run-length type `COPY_ABOVE`, or whether both the previous scanned pixel and the current pixel are run-length type `INDEX` and have the same index value. Otherwise, the signaling instruction is given with `run_copy_flag = 1`. If the pixel and the previous pixel have different patterns, a signaling instruction is given with a context-coded binary number `copy_above_palette_indices_flag`, indicating the run-length type of the pixel, i.e., `INDEX` or `COPY_ABOVE`. Similar to the palette mode in VTM 6.0, the decoder does not need to resolve the run-length type if the sample is in the first row (horizontal traversal scan) or the first column (vertical traversal scan), as index mode is used by default. Furthermore, if the previously resolved run-length type is COPY_ABOVE, the decoder does not need to resolve the run-length type. After palette run-length encoding / decoding of pixels in a segment, the index values ​​(for INDEX mode) and the quantized escaped colors are bypassed and grouped separately from the encoding / decoding of the context-encoded binary numbers to improve throughput within each line CG. Because the index values ​​are now encoded / decoded after run-length encoding / decoding, instead of being processed before palette run-length encoding / decoding as in VTM, the encoder does not need to signal the number of index values ​​num_palette_indices_minus1 and the final run-length type copy_above_indices_for_final_run_flag.

[0148] The text in some embodiments based on the line-based CG palette pattern is shown below.

[0149] Palette encoding / decoding syntax

[0150]

[0151]

[0152]

[0153]

[0154]

[0155]

[0156] 7.4.9.6 Palette Encoding and Decoding Semantics

[0157] In the following semantics, array indices x0 and y0 specify the position (x0, y0) of the top-left luminance sample of the codec block under consideration relative to the top-left luminance sample of the image. Array indices xC and yC specify the position (xC, yC) of this sample relative to the top-left luminance sample of the image. The array index startComp specifies the first color component of the current palette table. startComp equals 0 for the Y component; startComp equals 1 for the Cb component; and startComp equals 2 for the Cr component. numComps specifies the number of color components in the current palette table.

[0158] The predictor palette consists of palette entries from previous encoder-decoder units, which are used to predict entries in the current palette.

[0159] The variable PredictorPaletteSize[startComp] specifies the size of the predictor palette for the first color component of the current palette table startComp. PredictorPaletteSize is derived according to the provisions in Clause 8.4.5.3.

[0160] The variable `PalettePredictorEntryReuseFlags[i]` being equal to 1 indicates that the i-th entry in the predictor palette is reused in the current palette. `PalettePredictorEntryReuseFlags[i]` being equal to 0 indicates that the i-th entry in the predictor palette is not an entry in the current palette. All elements of the array `PalettePredictorEntryReuseFlags[i]` are initialized to 0.

[0161] The `palette_predictor_run` function determines the number of zeros preceding non-zero entries in the array `PalettePredictorEntryReuseFlags`.

[0162] The requirement for bitstream consistency is that the value of `palette_predictor_run` should be in the range of 0 to (`PredictorPaletteSize - predictorEntryIdx`), inclusive, where `predictorEntryIdx` corresponds to the current position in the array `PalettePredictorEntryReuseFlags`. The variable `NumPredictedPaletteEntries` specifies the number of entries reused from the predictor palette in the current palette. The value of `NumPredictedPaletteEntries` should be in the range of 0 to `palette_max_size`, inclusive.

[0163] num_signalled_palette_entries specifies the number of entries in the current palette that explicitly signal the first color component of the current palette table startComp.

[0164] When num_signalled_palette_entries does not exist, it is inferred to be equal to 0.

[0165] The variable CurrentPaletteSize[startComp] specifies the size of the current palette for the first color component of the current palette table startComp, and is deduced as follows:

[0166] CurrentPaletteSize[startComp]=NumPredictedPaletteEntries+num_signalled_palette_entries (7-155)

[0167] The value of CurrentPaletteSize[startComp] should be in the range of 0 to palette_max_size, inclusive.

[0168] new_palette_entries[cIdx][i] specifies the value of the i-th signaling palette entry for the color component cIdx.

[0169] The variable PredictorPaletteEntries[cIdx][i] specifies the i-th element in the predictor palette for the color component cIdx.

[0170] The variable CurrentPaletteEntries[cIdx][i] specifies the i-th element in the current palette for the color component cIdx, and is deduced as follows:

[0171]

[0172] A `palette_escape_val_present_flag` value of 1 indicates that the current codec unit contains at least one escaped coded sample. A `escape_val_present_flag` value of 0 indicates that there are no escaped coded samples in the current codec unit. When it does not exist, the value of `palette_escape_val_present_flag` is inferred to be 1.

[0173] The variable MaxPaletteIndex specifies the maximum possible value of the palette index for the current codec unit. The value of MaxPaletteIndex is set to equal CurrentPaletteSize[startComp]-1+palette_escape_val_present_flag.

[0174] palette_idx_idc is an indicator of the index of the palette table CurrentPaletteEntries. For the first index in the block, the value of palette_idx_idc should be in the range of 0 to MaxPaletteIndex, inclusive. For the remaining indices in the block, the value of palette_idx_idc should be in the range of 0 to MaxPaletteIndex-1, inclusive.

[0175] When palette_idx_idc does not exist, it is inferred to be equal to 0.

[0176] A palette_transpose_flag value of 1 specifies that a vertical traversal scan is applied to scan the indices of the samples in the current codec unit. A palette_transpose_flag value of 0 specifies that a horizontal traversal scan is applied to scan the indices of the samples in the current codec unit. If the palette_transpose_flag does not exist, its value is inferred to be 0.

[0177] The array TraverseScanOrder specifies the scan order array used for palette encoding and decoding. If palette_transpose_flag is equal to 0, TraverseScanOrder is assigned the horizontal scan order HorTravScanOrder; if palette_transpose_flag is equal to 1, TraverseScanOrder is assigned the vertical scan order VerTravScanOrder.

[0178] `run_copy_flag` equal to 1 specifies that if `copy_above_palette_indices_flag` equals 0, the palette run type is the same as the run type at the previous scan position, and the palette run index is the same as the index at the previous position. Otherwise, `run_copy_flag` equals 0.

[0179] `copy_above_palette_indices_flag` equal to 1 specifies that if a horizontal traversal scan is used, the palette index is equal to the palette index at the same position in the previous row; or if a vertical traversal scan is used, the palette index is equal to the palette index at the same position in the left column. `copy_above_palette_indices_flag` equal to 0 specifies that the indication of the sample's palette index is encoded or inferred in the bitstream.

[0180] CopyAboveIndicesFlag[xC][yC] equal to 1 indicates that the palette index is copied from the palette index in the previous row (horizontal scan) or the left column (vertical scan). CopyAboveIndicesFlag[xC][yC] equal to 0 indicates that the palette index is explicitly encoded or inferred in the bitstream. The array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left luminance sample of the image.

[0181] The variable PaletteIndexMap[xC][yC] specifies the palette index, which is the index of an array represented by CurrentPaletteEntries. The array indices xC and yC specify the position (xC, yC) of the sample relative to the top-left brightness sample of the image. The value of PaletteIndexMap[xC][yC] should be in the range of 0 to MaxPaletteIndex, inclusive.

[0182] The variable adjustedRefPaletteIndex is derived as follows:

[0183]

[0184]

[0185] When CopyAboveIndicesFlag[xC][yC] equals 0, the variable CurrPaletteIndex is deduced as follows:

[0186] if(CurrPaletteIndex>=adjustedRefPaletteIndex)

[0187] CurrPaletteIndex++ (7-158)

[0188] Palette_escape_val specifies the quantization escape codec sample value for a component.

[0189] The variable `PaletteEscapeVal[cIdx][xC][yC]` specifies the escape value of the sample, where `PaletteIndexMap[xC][yC]` equals `MaxPaletteIndex`, and `palette_escape_val_present_flag` equals 1. The array index `cIdx` specifies the color component. The array indices `xC` and `yC` specify the position (xC, yC) of the sample relative to the top-left luminance sample of the image.

[0190] The requirement for bitstream consistency is that, for cIdx equal to 0, PaletteEscapeVal[cIdx][xC][yC] should be between 0 and (1 << (BitDepth)). Y The range is +1))-1, including the endpoint. For cIdx not equal to 0, then it is within the range of 0 to (1<<(BitDepth)). C The range is +1))-1, including the endpoints.

[0191] 2.3 Local Double Trees in VVC

[0192] In typical hardware video encoders and decoders, processing throughput decreases as the image has more small intra-blocks due to the data dependency of sample processing between adjacent intra-blocks. Predictor generation for intra-blocks requires reconstructed samples from the top and left boundaries of adjacent blocks. Therefore, intra-prediction must be processed sequentially, block by block.

[0193] In HEVC, the smallest intra-frame prediction unit (CU) is an 8×8 luma sample. The luma component of the smallest intra-frame CU can be further subdivided into four 4×4 luma intra-frame prediction units (PUs), but the chroma component of the smallest intra-frame CU cannot be further subdivided. Therefore, the hardware processing throughput is worst when processing 4×4 chroma intra-frame blocks or 4×4 luma intra-frame blocks.

[0194] In VTM 5.0, within a single codec tree, since chroma segmentation always follows luma, and the minimum intra-frame CU is 4×4 luma samples, the minimum intra-chroma CB is 2×2. Therefore, in VTM 5.0, the minimum intra-chroma CB in a single codec tree is 2×2. The worst-case hardware processing throughput of VVC decoding is only 1 / 4 that of HEVC decoding. Furthermore, after employing tools including Cross Component Linear Model (CCLM), 4-tap interpolation filters, Position-dependent Intra-Prediction Combination (PDPC), and Combined Inter-Frame Intra-Prediction (CIIP), the reconstruction process of intra-chroma CB becomes significantly more complex than in HEVC. Achieving high processing throughput in the hardware decoder is challenging. In this section, we propose a method to improve worst-case hardware processing throughput.

[0195] The goal of this method is to prohibit intra-chroma CBs with fewer than 16 chroma samples by constraining the segmentation of intra-chroma CBs.

[0196] In a single codec tree, a SCIPU is defined as a codec tree node with a chroma block size greater than or equal to TH chroma samples and at least one sub-luminance block with less than 4TH luma samples, where TH is set to 16 in this proposal. It is required that in each SCIPU, all CBs are either inter-frame or non-inter-frame, i.e., intra-frame or IBC. In the case of non-inter-frame SCIPUs, it is further required that the chroma of the non-inter-frame SCIPU should not be further subdivided, while the luma of the SCIPU is allowed to be further subdivided. In this way, the minimum chroma intra-frame CB size is 16 chroma samples, and 2×2, 2×4, and 4×2 chroma CBs are removed. Furthermore, chroma scaling is not applied in the case of non-inter-frame SCIPUs. Additionally, a local dual-tree codec structure is constructed when the luma block is further subdivided while the chroma block is not.

[0197] Figures 5A-5B Two SCIPU examples are shown. Figure 5A In this context, one chromaticity CB and three luminance CBs (4×8, 8×8, and 4×8 luminance CBs) from an 8×4 chromaticity sample point form a SCIPU because the ternary tree (TT) partitioned from the 8×4 chromaticity sample point will result in fewer than 16 chromaticity sample points for the chromaticity CB. Figure 5B In the diagram, one chromaticity CB (to the left of the 8×4 chromaticity sample) and three luminance CBs (8×4, 4×4, and 4×4 luminance CBs) from a 4×4 chromaticity sample form a SCIPU, and another chromaticity CB (to the right of the 8×4 chromaticity sample) from a 4×4 sample and two luminance CBs (8×4 and 8×4 luminance CBs) form a SCIPU, because the binary tree (BT) partitioned from the 4×4 chromaticity sample will result in fewer than 16 chromaticity samples for the chromaticity CB.

[0198] In the proposed method, if the current stripe is an I stripe or the current SCIPU has a 4×4 luminance segmentation in it after being further divided once (because 4×4 is not allowed between frames in VVC), the type of SCIPU is inferred to be non-inter-frame; otherwise, the type of SCIPU (inter-frame or non-inter-frame) is indicated by a signaling flag before resolving the CU in the SCIPU.

[0199] By applying the above method, the worst-case hardware throughput is obtained when processing 4×4, 2×8, or 8×2 chroma blocks instead of 2×2 chroma blocks. The worst-case hardware throughput is the same as HEVC, and four times that of VTM5.0.

[0200] 2.4 Transform Skip (TS)

[0201] In HEVC, block residuals can be encoded and decoded in transform-skip mode. To avoid redundancy in syntax encoding and decoding, the transform-skip flag is not signaled when the CU-level MTS_CU_flag is not equal to zero. The block size limit for transform-skip is the same as the block size limit for MTS in JEM4, indicating that transform-skip applies to the CU when both the block width and height are equal to or less than 32. Note that when LFNST or MIP is activated for the current CU, the implicit MTS transform is set to DCT2. Furthermore, implicit MTS can still be enabled when MTS is enabled for inter-frame encoding / decoding blocks.

[0202] Furthermore, for transform skip blocks, the minimum allowed quantization parameter (QP) is defined as 6*(internalBitDepth–inputBitDepth)+4.

[0203] 2.5 Replacement Luminance Half-Pixel Interpolation Filter

[0204] In some embodiments, alternative half-pixel interpolation filters are proposed.

[0205] The switching of the half-pixel luma interpolation filter depends on the motion vector accuracy. In addition to the existing quarter-pixel, full-pixel, and 4-pixel AMVR modes, a new half-pixel precision AMVR mode has been introduced. An alternative half-pixel luma interpolation filter can only be selected when half-pixel motion vector precision is achieved.

[0206] For non-affine inter-frame codecs (CUs) using half-pixel motion vector accuracy (i.e., half-pixel AMVR mode), the value of the new syntax element hpelIfIdx is used to switch between the HEVC / VVC half-pixel luma interpolation filter and one or more alternative half-pixel interpolations. The hpelIfIdx syntax element is signaled only in half-pixel AMVR mode. In skip / merge modes using spatial merging candidates, the value of the hpelIfIdx syntax element is inherited from neighboring blocks.

[0207] 2.6 Adaptive Color Transformation (ACT)

[0208] Figure 6 The diagram illustrates the decoding flowchart for the ACT application. Figure 6 As shown, the color space conversion is performed in the residual domain. Specifically, an additional decoding module, the inverse ACT, is introduced after the inverse transform to convert the residual from the YCgCo domain back to the original domain.

[0209] In VVC, a CU leaf node is also used as the unit of transform processing unless the maximum transform size is less than the width or height of a codec unit (CU). Therefore, in the proposed implementation, a CU is signaled with an ACT flag to select the color space for encoding and decoding its residuals. Furthermore, following the HEVC ACT design, for inter-frame and IBC CUs, ACT is enabled only if the CU has at least one non-zero coefficient. For intra-frame CUs, ACT is enabled only if the chroma component selects the same intra-frame prediction mode (i.e., DM mode) as the luma component.

[0210] The core transformation used for color space conversion remains the same as that used for HEVC. Specifically, the following forward and inverse YCgCo color transformation matrices are applied, as described below.

[0211]

[0212] In addition, to compensate for the change in dynamic range of the residual signal before and after color transformation, a QP adjustment of (-5, -5, -3) is applied to the transformation residual.

[0213] On the other hand, both forward and inverse color transformations require access to the residuals of all three components. Accordingly, in the proposed implementation, ACT is disabled in two cases where not all residuals of the three components are available.

[0214] 1. Split Tree Segmentation: When a split tree is applied, the luminance and chrominance samples within a CTU are segmented by different structures. This results in the CU in the luminance tree containing only the luminance component, while the CU in the chrominance tree contains only the two chrominance components.

[0215] 2. Intra-Frame Sub-Segmentation Prediction (ISP): ISP sub-segmentation is applied only to luma, while the chroma signal is encoded and decoded without segmentation. In current ISP designs, except for the final ISP sub-segmentation, other sub-segments contain only the luma component.

[0216] 2.7 Binarization using the escape value of EG(k)

[0217] When using EG(k) for escape value binarization, the bit length of EG(k) cannot be reduced further when the radix Qp is sufficiently large (or the symbols to be encoded / decoded are sufficiently small). For example, when the radix Qp >= 23, the bit length reaches 6 for EG(5), which is the minimum bit length for EG5. Similarly, when the radix Qp >= 35, the bit length reaches the minimum value for EG3. When the radix Qp >= 29, the bit length reaches the minimum value for EG4. In these cases, further increasing Qp will not reduce the bit rate but will increase distortion. This is a waste of bits.

[0218] 3. Example technical problems solved by the technical solutions described herein

[0219] 1. When Qp is greater than the threshold, EG(k), which is the binary representation of the escaped value, may waste bits.

[0220] 2. The palette size may be too large for local dual-tree applications.

[0221] 3. When chroma tools are not used, signaling is not required to notify chroma parameters.

[0222] 4. Example embodiments and techniques

[0223] The following list of items should be considered as examples for explaining general concepts. These items should not be interpreted in a narrow way.

[0224] Furthermore, these projects can be combined in any way.

[0225] The following examples can be applied to palette schemes in VVC and all other palette-related schemes.

[0226] 1. The Qp used for escape value reconstruction can have a maximum and / or minimum allowed value.

[0227] a. In one example, QP can be limited to no greater than the maximum allowable value and / or no less than the minimum allowable value.

[0228] b. In one example, the maximum allowed Qp for reconstructing escape values ​​can depend on the binaryization method.

[0229] c. In one example, the maximum allowed Qp for escape value reconstruction could be (T+B), where B is based on the bit depth.

[0230] i. In one example, T can be a constant.

[0231] 1. In one example, T can be 23.

[0232] 2. In one example, T can be a number less than 23.

[0233] 3. In one example, T can be 35.

[0234] 4. In one example, T can be a number less than 35.

[0235] 5. In one example, T can be 29.

[0236] 6. In one example, T can be a number less than 29.

[0237] ii. In one example, T can be indicated in a video region (e.g., sequence, image, strip / slice / sub-image).

[0238] 1. In one example, T can be indicated in VPS / SPS / PPS / PH / SH.

[0239] iii. In one example, B can be set to QpBdOffset (e.g., 6*bit_depth_minus8).

[0240] d. In one example, the maximum allowed Qp for escape value reconstruction could be (23 + QpBdOffset).

[0241] i. Alternatively, EG5 can be used to encode and decode escape values.

[0242] ii. Alternatively, the maximum allowed Qp for escape value reconstruction can be (K + QpBdOffset), where K is a number less than 23.

[0243] e. In one example, the maximum allowed Qp for escape value reconstruction could be (35 + QpBdOffset).

[0244] i. Alternatively, EG3 can be used to encode and decode escape values.

[0245] ii. Alternatively, the maximum allowed Qp for escape value reconstruction can be (K + QpBdOffset), where K is a number less than 35.

[0246] f. Alternatively, the maximum allowed Qp for escape value reconstruction can be (29 + QpBdOffset).

[0247] i. Alternatively, EG4 can be used to encode and decode escape values.

[0248] ii. Alternatively, the maximum allowed Qp for escape value reconstruction can be (K + QpBdOffset), where K is a number less than 29.

[0249] Palette size related

[0250] 2. It is proposed that the palette size can be different when applying or not applying local dual trees.

[0251] a. In one example, for a local dual tree, it is proposed that the palette size can be reduced.

[0252] b. In one example, when a local dual-tree is applied, the palette sizes for the luminance CU and chrominance CU can be different.

[0253] c. In one example, the palette size of the chromaticity CU can be reduced compared to the palette size of the luminance CU in a local dual tree, or compared to the palette size when no local dual tree is applied.

[0254] i. In one example, the size of the palette used for chroma can be halved.

[0255] 3. It is proposed that the size of the palette predictor can be different when a local dual tree is applied or not.

[0256] a. In one example, for a local dual-tree, it is proposed that the size of the palette predictor can be reduced.

[0257] b. In one example, when a local dual-tree is applied, the palette predictor sizes for the luminance CU and chrominance CU can be different.

[0258] c. In one example, the palette predictor size of the chromaticity CU can be reduced compared to the palette predictor size of the luminance CU in a local dual tree, or compared to the palette predictor size when no local dual tree is applied.

[0259] i. In one example, the size of the palette predictor used for chromaticity can be halved.

[0260] Color deblocking related

[0261] 4. Whether the signaling notification / resolution of chroma deblocking offset at the stripe level and / or higher (i.e., the area size is larger than the stripe) (e.g., in PPS or picture header) may depend on the color format and / or the Separate Plane Codec Enable flag and / or the ChromaArrayType and / or the flag indicating whether the chroma deblocking offset exists and / or the flag indicating whether the chroma deblocking offset or some other chroma tool parameter exists.

[0262] a. In one example, when ChromaArrayType equals 0 or the color format is 4:0:0 or a separate planar codec is applied or a flag indicates that the chroma deblocking offset does not exist, signaling notification / parsing for the chroma deblocking offset at the stripe level and / or higher (i.e., the area size is larger than the stripe) can always be skipped.

[0263] b. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or a flag indicating that the chroma deblocking offset does not exist, the signaling notifications / parsing for pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 can always be skipped.

[0264] c. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or a flag indicating that the chroma deblocking offset does not exist, the signaling notifications / parsing for ph_cb_beta_offset_div2, ph_cb_tc_offset_div2, ph_cr_beta_offset_div2, and ph_cr_tc_offset_div2 can always be skipped.

[0265] d. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or a flag indicating that the chroma deblocking offset does not exist, the signaling notification / parsing for slice_cb_beta_offset_div2, slice_cb_tc_offset_div2, slice_cr_beta_offset_div2, and slice_cr_tc_offset_div2 can always be skipped.

[0266] e. Alternatively, the consistent bitstream should satisfy that pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 should be equal to 0 when ChromaArrayType is equal to 0, the color format is 4:0:0, or a separate planar codec is applied.

[0267] f. In one example, when chroma_format_idc equals 0 and separate_colour_plane_flag is not equal to 1 or the flag indicating that the chroma deblocking offset does not exist, the signaling notifications / parsing of pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 can always be skipped.

[0268] g. In one example, when chroma_format_idc equals 0 and separate_colour_plane_flag is not equal to 1 or the flag indicating that the chroma deblocking offset does not exist, the signaling notifications / parsing of pps_cb_beta_offset_div2, ph_cb_tc_offset_div2, ph_cr_beta_offset_div2, and ph_cr_tc_offset_div2 can always be skipped.

[0269] h. In one example, when chroma_format_idc equals 0 and separate_colour_plane_flag is not equal to 1 or the flag indicating that the chroma deblocking offset does not exist, the signaling notification / parsing of slice_cb_beta_offset_div2, slice_cb_tc_offset_div2, slice_cr_beta_offset_div2, and slice_cr_tc_offset_div2 can always be skipped.

[0270] i. Alternatively, when the signaling notification of a syntax element is skipped, the value of the syntax element is inferred to be equal to 0.

[0271] 5. Color format and / or off-plane encoding / decoding enable flags and / or ChromaArrayType and / or flags indicating whether chroma deblocking offset exists and / or flags indicating whether chroma deblocking offset or some other chroma tool parameters exist (e.g., pps_chroma_tool_params_present_flag) can be indicated in PPS and / or SPS and / or APS.

[0272] a. In one example, when ChromaArrayType equals 0 or the color format is 4:0:0 and / or the flag is false, the signaling notifications / parsing of pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 can always be skipped.

[0273] b. In one example, when ChromaArrayType equals 0 or the color format is 4:0:0 and / or the flag is false, the signaling notifications / parsing of pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 can always be skipped.

[0274] c. In one example, under a conditional check where ChromaArrayType is not equal to 0 and / or the flag is false, the signaling notifies the chroma tool to offset the relevant syntax element (e.g.,

[0275] pps_cb_qp_offset,

[0276] pps_cr_qp_offset,pps_joint_cbcr_qp_offset_present_flag,pps_slice_chroma_qp_offsets_present_flag,

[0277] pps_cu_chroma_qp_offset_list_enabled_flag).

[0278] d. In a consistent bitstream, the color format and / or separate planar codec enable flags and / or ChromaArrayType of the signaling notification in the PPS should be the same as the corresponding information in the associated SPS signaling notification.

[0279] 6. The flag that controls whether signaling notification / resolution of chroma QP offset should be provided can also control whether signaling notification / resolution of chroma deblock offset should be provided.

[0280] a. In one example, the flag pps_chroma_tool_params_present_flag can be used to control whether signaling notification / resolution of chroma QP offsets and whether signaling notification / resolution of chroma deblocking offsets should be performed (e.g., as shown in Example 3). Alternatively, the existing flag pps_chroma_tool_offsets_present_flag can be used to control whether signaling notification / resolution of chroma QP offsets and whether signaling notification / resolution of chroma deblocking offsets should be performed.

[0281] 7. Control flags, such as pps_chroma_deblocking_params_present_flag, can be added in PPS to control whether signaling notifications / resolution of chroma deblocking offsets should be used.

[0282] a. In one example, when the flag is equal to 0, the signaling notifications / parsing of pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2, and pps_cr_tc_offset_div2 can always be skipped.

[0283] b. In one example, when the flag is equal to 0, the signaling notifications / parsing of ph_cb_beta_offset_div2, ph_cb_tc_offset_div2, ph_cr_beta_offset_div2, and ph_cr_tc_offset_div2 can always be skipped.

[0284] c. In one example, when the flag is equal to 0, signaling notifications / parsing for slice_cb_beta_offset_div2, slice_cb_tc_offset_div2, slice_cr_beta_offset_div2, and slice_cr_tc_offset_div2 can always be skipped.

[0285] d. Alternatively, in a consistent bitstream, when ChromaArrayType equals 0, the requirement flag should be equal to 0.

[0286] Parameters related to the colorimeter tool in APS

[0287] 8. Control flags, such as aps_chroma_tool_params_present_flag, can be added in the APS to control whether signaling notifications / parsing of chroma tool-related parameters should be displayed in the APS.

[0288] a. In one example, when aps_chroma_tool_params_present_flag equals 0, alf_chroma_filter_signal_flag, alf_cc_cb_filter_signal_flag, and alf_cc_cr_filter_signal_flag can always be skipped and inferred to be equal to 0.

[0289] b. In one example, when aps_chroma_tool_params_present_flag equals 0, scaling_list_chroma_present_flag can always be skipped and inferred to be equal to 0.

[0290] Other chromaticity tool parameters in the image header

[0291] 9. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or the flag indicating that the syntax element ph_log2_diff_min_qt_min_cb_intra_slice_luma (and possibly other syntax elements) does not exist, the signaling notification / parsing of ph_log2_diff_min_qt_min_cb_intra_slice_luma can always be skipped.

[0292] 10. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or the flag indicating that the syntax element ph_log2_diff_min_qt_min_cb_intra_slice_chroma (and possibly other syntax elements) does not exist, the signaling notification / parsing of ph_log2_diff_min_qt_min_cb_intra_slice_chroma can always be skipped.

[0293] 11. In one example, when ChromaArrayType equals 0, or the color format is 4:0:0, or a separate planar codec is applied, or the flag indicating that the syntax element ph_log2_diff_min_qt_min_cb_inter_slic (and possibly other syntax elements) does not exist, the signaling notification / parsing of ph_log2_diff_min_qt_min_cb_inter_slice can always be skipped.

[0294] General characteristics

[0295] 12. Whether and / or how to apply the above methods can be based on:

[0296] a. Video content (e.g., screen content or natural content)

[0297] b. Signaling notification messages in DPS / SPS / VPS / PPS / APS / Picture Header / Strip Header / Piece Group Header / Maximum Codec Unit (LCU) / Codec Unit (CU) / LCU Line / LCU Group / TU / PU Block / Video Codec Unit

[0298] c. Location of CU / PU / TU / block / video encoding / decoding unit

[0299] d. Block dimensions of the current block and / or its neighboring blocks

[0300] e. Block shape of the current block and / or its adjacent blocks

[0301] f. Quantization parameters of the current block

[0302] g. Indication of color format (such as 4:2:0, 4:4:4, RGB, or YUV)

[0303] h. Encoding / decoding tree structures (such as dual-tree or single-tree)

[0304] i. Strip / group type and / or image type

[0305] j. Color components (e.g., may be applied only to the luminance and / or chrominance components)

[0306] k. Temporal layer ID

[0307] l. Standard configuration files / levels / hierarchies

[0308] m. Does the current block have an escaped sample?

[0309] i. In one example, the above method can only be applied if the current block has at least one escape sample point.

[0310] n. Whether the current block is encoded or decoded in lossless mode (e.g., cu_transquant_bypass_flag).

[0311] ii. In one example, the above method can only be applied if the current block is not encoded or decoded in lossless mode.

[0312] o. Whether lossless encoding / decoding is enabled (e.g., transquant_bypass_enabled, cu_transquant_bypass_flag)

[0313] 5. Examples

[0314] In the following embodiments, the added portions are marked as bold, underlined, and italic text. The deleted portions are marked within [[]].

[0315] 5.1 Example #1

[0316] 8.4.5.3 Decoding process of palette mode

[0317] – If bIsEscapeSample equals 0, then the following applies:

[0318] recSamples[x][y]=CurrentPaletteEntries[cIdx][PaletteIndexMap[xCbL+xL][yCbL+yL]] (443)

[0319] Otherwise (bIsEscapeSample equals 1), the following ordered steps will be applied:

[0320] 1. The quantization parameter qP is derived as follows:

[0321] –If cIdx equals 0

[0322]

[0323] Otherwise, if cIdx equals 1,

[0324]

[0325] Otherwise (cIdx equals 2),

[0326]

[0327] 2. The list levelScale[] is specified as levelScale[k] = {40, 45, 51, 57, 64, 72}, where k = 0..5.

[0328] 3. The following applies:

[0329] tmpVal=(PaletteEscapeVal[cIdx][xCbL+xL][yCbL+yL]*levelScale[qP%6])<<(qP / 6)+32)>>6 (447)

[0330] recSamples[x][y]=Clip3(0,(1< <BitDepth)-1,tmpVal) (448)

[0331] 5.2 Example #2

[0332] 7.3.2.4 Image Parameter Set RBSP Syntax

[0333]

[0334]

[0335] 7.3.2.7 Image Header Structure Syntax

[0336]

[0337]

[0338] 7.3.7.1 General Strip Header Syntax

[0339]

[0340] 5.3 Example #3

[0341] 7.4.2.4 Image Parameter Set RBSP Syntax

[0342]

[0343]

[0344] 7.3.2.5 Adaptive Parameter Set (RBSP) Syntax

[0345]

[0346]

[0347] 7.3.2.7 Image Header Structure Syntax

[0348]

[0349]

[0350]

[0351]

[0352] 7.3.2.19 Adaptive Loop Filter Data Syntax

[0353]

[0354] 7.3.2.21 Scaling List Data Syntax

[0355]

[0356] 7.3.7.1 General Strip Header Syntax

[0357]

[0358]

[0359] 7.4.3.4 Image Parameter Set RBSP Semantics

[0360] ...

[0361] An equal value of 1 indicates that the PPS RBSP syntax structure contains a syntax element related to the chroma tool [[offset]]. A value of 0 indicates that there are no syntax elements related to the chroma tool [[offset]] in the PPS RBSP syntax structure. When ChromaArrayType equals 0, The value should be equal to 0.

[0362] ...

[0363] 7.4.3.5 Adaptive Parameter Set Semantics

[0364] ...

[0365]

[0366] ...

[0367] 5.4 Example #4

[0368] 7.4.2.4 Image Parameter Set RBSP Syntax

[0369]

[0370] 7.3.2.7 Image Header Structure Syntax

[0371]

[0372]

[0373] 7.3.7.1 General Strip Header Syntax

[0374]

[0375]

[0376] 7.4.3.4 Image Parameter Set RBSP Semantics

[0377] ...

[0378] A value of 1 indicates that the PPS RBSP syntax structure contains chroma deblocking related syntax elements. A value of 0 indicates that the PPS RBSP syntax structure does not contain chroma deblocking related syntax elements. When ChromaArrayType equals 0, the value of pps_chroma_deblocking_params_present_flag should be 0.

[0379] ...

[0380] Figure 7 This is a block diagram illustrating an example video processing system 1900 in which various techniques disclosed herein may be implemented. Various implementations may include some or all of the components of system 1900. System 1900 may include an input 1902 for receiving video content. The video content may be received in a raw or uncompressed format, such as 8 or 10-bit multi-component pixel values, or it may be in a compressed or encoded format. Input 1902 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 Network (PON), etc., and wireless interfaces such as Wi-Fi or cellular interfaces.

[0381] System 1900 may include codec component 1904, which can implement the various codec or encoding methods described in this document. Codec component 1904 can reduce the average bit rate of the video from input 1902 to the output of codec component 1904 to produce an encoded representation of the video. Therefore, codec techniques are sometimes referred to as video compression or video transcoding techniques. As indicated by component 1906, the output of codec component 1904 can be stored or transmitted via connected communication. Component 1908 can use the stored or transmitted bitstream (or encoded) representation of the video received at input 1902 to generate pixel values ​​or displayable video sent to display interface 1910. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. Furthermore, although some video processing operations are referred to as “codec” operations or tools, it should be understood that encoding tools or operations are used at the encoder, and corresponding decoding tools or operations, the opposite of the encoding result, will be performed by the decoder.

[0382] Examples of peripheral bus interfaces or display interfaces may include Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or DisplayPort. Examples of storage interfaces include SATA (Serial Advanced Technology Accessory), PCI, IDE, etc. The technologies described in this document can be implemented in a variety of electronic devices, such as mobile phones, laptops, smartphones, or other devices capable of performing digital data processing and / or video display.

[0383] Figure 8 This is a block diagram of a video processing apparatus 3600. Apparatus 3600 can be used to implement one or more methods described herein. Apparatus 3600 can be embodied in smartphones, tablets, computers, Internet of Things (IoT) receivers, etc. Apparatus 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. Processors (or more) 3602 can be configured to implement one or more methods described in this document. Memory (or more) 3604 can be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 3606 can be used to implement some of the techniques described in this document in hardware circuitry.

[0384] Figure 10 This is a block diagram illustrating an example video encoding / decoding system 100 that can utilize the technology of the present invention.

[0385] like Figure 10 As shown, the video encoding / decoding system 100 may include a source device 110 and a destination device 120. The source device 110 generates encoded video data, which may be referred to as a video encoding device. The destination device 120 can decode the encoded video data generated by the source device 110, which may be referred to as a video decoding device.

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

[0387] Video source 112 may include sources such as video capture devices, interfaces for receiving video data from video content providers, and / or computer graphics systems used to generate video data, or combinations of these sources. Video data may include one or more pictures. Video encoder 114 encodes the video data from video source 112 to generate a bitstream. The bitstream may include a sequence of bits forming a codec representation of the video data. The bitstream may include codec pictures and related data. A codec picture is a codec representation of a picture. Related data may include sequence parameter sets, picture parameter sets, and other syntax structures. I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. Encoded video data may be transmitted directly to destination device 120 via network 130a through I / O interface 116. Encoded video data may also be stored on storage medium / server 130b for access by destination device 120.

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

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

[0390] The video encoder 114 and the video decoder 124 can operate according to video compression standards, such as the High Efficiency Video Codec (HEVC) standard, the Universal Video Codec (VVM) standard, and other current and / or further standards.

[0391] Figure 11 This is a block diagram illustrating an example of a video encoder 200. The video encoder 200 can be... Figure 10 The video encoder 114 in the system 100 shown.

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

[0393] The functional components of the video encoder 200 may include a segmentation unit 201, a prediction unit 202 (including a mode selection unit 203), a motion estimation unit 204, a motion compensation unit 205, 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.

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

[0395] Furthermore, some components, such as the motion estimation unit 204 and the motion compensation unit 205, can be highly integrated, but for interpretative purposes... Figure 11 The example is shown separately.

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

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

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

[0399] The motion estimation unit 204 and the motion compensation unit 205 can perform different operations on the current video block, for example, depending on whether the current video block is in an I-band, P-band, or B-band.

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

[0401] In other examples, motion estimation unit 204 can perform bidirectional prediction on the current video block. Motion estimation unit 204 can search for a reference video block for the current video block in the reference images in list 0, and also search for another reference video block for the current video block in the reference images in list 1. Motion estimation unit 204 can then generate a reference index indicating the reference images in list 0 or list 1 that contain the reference video block, and a motion vector indicating the spatial displacement between the current video block and the reference video block. Motion estimation unit 204 can output the reference index and motion vector of the current video block as the motion information of the current video block. Motion compensation unit 205 can generate a predicted video block for the current video block based on the reference video block indicated by the motion information of the current video block.

[0402] In some examples, the motion estimation unit 204 can output complete motion information for the decoder's decoding processing.

[0403] In some examples, motion estimation unit 204 may not output the complete set of motion information for the current video. Instead, motion estimation unit 204 may signal the motion information of the current video block by referencing the motion information of another video block. For example, motion estimation unit 204 may determine that the motion information of the current video block is sufficiently similar to the motion information of neighboring video blocks.

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

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

[0406] As described above, the video encoder 200 can predictively signal motion vectors. Two examples of predictive signaling notification techniques that can be implemented by the video encoder 200 include Advanced Motion Vector Prediction (AMVP) and merge pattern signaling.

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

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

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

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

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

[0412] Inverse quantization unit 210 and inverse transform unit 211 can apply inverse quantization and inverse transform to the transform coefficient video block, respectively, to reconstruct the residual video block from the transform coefficient video block. Reconstruction unit 212 can add the reconstructed residual video block to the corresponding samples of one or more predicted video blocks generated by prediction unit 202 to generate a reconstructed video block associated with the current block, which is stored in buffer 213.

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

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

[0415] Figure 12 This is a block diagram illustrating an example of a video decoder 300, which can be... Figure 10 The video decoder 114 in the system 100 shown.

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

[0417] exist Figure 12 In the example, the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 can perform functions typically associated with the video encoder 200. Figure 11 The decoding process is the inverse of the encoding process described.

[0418] The entropy decoding unit 301 can retrieve the encoded bitstream. The encoded bitstream may include entropy-coded video data (e.g., encoded video data blocks). The entropy decoding unit 301 can decode the entropy-coded video data, and the motion compensation unit 302 can determine motion information, including motion vectors, motion vector precision, reference image list index, and other motion information, from the entropy-decoded video data. The motion compensation unit 302 can determine this information, for example, by executing AMVP and merge modes.

[0419] The motion compensation unit 302 can generate motion compensation blocks and can perform interpolation based on an interpolation filter. The syntax elements can include identifiers of the interpolation filters to be used with sub-pixel precision.

[0420] The motion compensation unit 302 can use interpolation filters, such as those used by the video encoder 200 during the encoding of video blocks, to calculate the interpolation of sub-integer pixels of the reference block. The motion compensation unit 302 can determine the interpolation filter used by the video encoder 200 based on the received syntax information and use the interpolation filter to generate the prediction block.

[0421] The motion compensation unit 302 can use some syntax information to determine the size of the blocks of frames and / or stripes used to encode the encoded video sequence, segmentation information describing how each macroblock of the image of the encoded video sequence is segmented, a mode indicating how each segment is encoded, one or more reference frames (and a list of reference frames) for each inter-frame encoded block, and other information for decoding the encoded video sequence.

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

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

[0424] The following is a list of preferred solutions for some embodiments.

[0425] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., Project 1).

[0426] 1. A video processing method (e.g., Figure 9 The method 900 described herein includes: performing (902) a conversion between a video block of a video and a codec representation of the video, wherein a palette mode is applied to the codec representation of the video block, in which a palette of representative color values ​​is used to represent samples of the video block; and wherein samples outside the palette are encoded and decoded using an escape character and values ​​quantized using a quantization parameter within a range between a minimum and a maximum permissible value determined by rules.

[0427] 2. The method according to Solution 1, wherein the maximum allowed value depends on the binary representation of the video block's codec representation.

[0428] 3. The method according to Solution 1, wherein the maximum allowed value is represented as T+B, where B is a number representing the bit depth of the sample points of the video block and T is a predefined number.

[0429] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., Project 2).

[0430] 4. A video processing method, comprising: performing a conversion between video blocks of a video and a codec representation of the video, wherein a palette mode is applied to the codec representation of the video blocks, wherein a palette of representative color values ​​is used to represent samples of the video blocks in the palette mode; and wherein the size of the palette depends on a rule regarding whether a local bitree is applied to the conversion between the video blocks and the codec representation.

[0431] 5. The method described in Solution 4, wherein, due to the use of a local dual tree, the size of the color palette depends on the color components of the video.

[0432] 6. According to the method described in Solution 5, the rule specifies that a smaller palette size should be used when the video block is a chroma block than when the video block is a luma block.

[0433] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., Project 3).

[0434] 7. A video processing method, comprising: performing a conversion between video blocks of a video and a codec representation of the video, wherein a palette mode is used in the codec representation of the video blocks, wherein a palette of representative color values ​​is used to represent samples of the video blocks in the palette mode; and wherein the size of the palette predictor depends on a rule regarding whether a local bitree is used in the conversion between the video blocks and the codec representation.

[0435] 8. The method according to Solution 7, wherein, due to the use of a local dual tree, the size of the palette predictor depends on the color components of the video block.

[0436] 9. According to the method described in Solution 8, the rule specifies that a smaller palette size should be used when the video block is a chroma block than when the video block is a luma block.

[0437] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., Project 4).

[0438] 10. A video processing method, comprising: for a conversion between a video block of a video region and a codec representation of the video, determining, based on codec conditions, whether a syntax element identifying a deblocking offset of the chroma components of the video is included in the codec representation at the video region level; and performing the conversion based on the determination; wherein the deblocking offset is used to selectively enable deblocking operations on the video block.

[0439] 11. The method according to solution 10, wherein the video region is a video strip or a video image.

[0440] 12. The method according to any one of solutions 10-11, wherein the encoding / decoding conditions include the color format of the video.

[0441] 13. The method according to any one of solutions 10-12, wherein the encoding / decoding conditions are based on whether separate planar encoding / decoding is enabled for the conversion.

[0442] 14. The method according to any one of solutions 10-13, wherein the encoding deconditioning is based on whether the chroma array type is included in the encoding / decoding representation.

[0443] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., Project 5).

[0444] 15. A video processing method, comprising: a conversion between a video block of a video region and a codec representation of the video; determining, based on codec conditions, whether a syntax element indicating the use of a chroma codec tool is included in the codec representation at the video region level; and performing the conversion based on the determination; wherein a deblocking offset is used to selectively enable deblocking operations on the video block.

[0445] 16. The method according to solution 15, wherein the video region is a video strip or a video image.

[0446] 17. The method according to any one of solutions 15-16, wherein the encoding / decoding conditions correspond to including syntax elements in the adaptive parameter set.

[0447] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., items 6 and 7).

[0448] 18. A video processing method comprising: performing a conversion between a video block of a video region of a video and a codec representation of the video, wherein the codec representation conforms to a format; wherein the format specifies whether a first flag indicating a deblocking offset of a video chroma component is included in the codec representation is based on whether a second flag indicating a quantization parameter offset of a chroma component is included in the codec representation.

[0449] 19. The method according to solution 18, wherein the format rule specifies that the codec representation includes a third flag, the third flag indicating whether the first flag and the second flag are included in the codec representation.

[0450] 20. The method according to any one of solutions 18-19, wherein the third flag is included in the encoding / decoding representation of the image parameter set.

[0451] The following solutions illustrate example embodiments of the techniques discussed in the previous section (e.g., items 8-12).

[0452] 21. A video processing method, comprising: performing a conversion between a video block of a video region and a codec representation of the video, wherein the codec representation conforms to a format rule; wherein the format rule specifies whether one or more parameters indicating the applicability of one or more chroma codec tools are included in the codec representation of the video region or video block.

[0453] 22. The method according to solution 21, wherein the syntax elements are included in the adaptive parameter set.

[0454] 23. The method according to any one of solutions 21-22, wherein the format rule specifies that the first value of the syntax element indicates that one or more parameters are excluded from the codec representation and are skipped during the parsing of the codec representation.

[0455] 24. The method according to any one of the foregoing solutions, wherein the conversion is performed using the method because the video meets the conditions.

[0456] 25. The method according to solution 24, wherein the conditions include encoding / decoding representing the type, profile, level, or hierarchy of the video content used.

[0457] 26. The method according to any one of the foregoing solutions, wherein the conditions include the block dimension of the video block and / or adjacent video blocks, or the color format of the video, or the codec tree structure used for video block conversion, or the type of the video region.

[0458] 27. The method according to any one of solutions 1 to 26, wherein the conversion includes encoding the video into a codec representation.

[0459] 28. The method according to any one of solutions 1 to 26, wherein the conversion includes decoding the encoding / decoding representation to generate pixel values ​​of the video.

[0460] 29. A video decoding apparatus, comprising a processor configured to implement one or more of the methods described in solutions 1 to 28.

[0461] 30. A video encoding apparatus, comprising a processor configured to implement one or more of the methods described in solutions 1 to 28.

[0462] 31. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method of any one of solutions 1 to 28.

[0463] 32. The methods, apparatus or systems described in this document.

[0464] Figure 13 This is a flowchart representation of a video processing method 1300 according to the present technology. Method 1300 includes, in operation 1310, performing a conversion between video blocks and the video bitstream according to a rule specifying whether a syntax element identifying the deblocking offset of the video's chroma components is included at the video region level, based on the video's color format. In some embodiments, the syntax element is omitted when the video's color format is 4:0:0. In some embodiments, the color format is determined based on the parameter ChromaArrayType.

[0465] Figure 14 This is a flowchart representation of a video processing method 1400 according to the present technology. Method 1400 includes, in operation 1410, performing a conversion between video blocks and the video bitstream according to a rule specifying whether a syntax element identifying the deblocking offset of the video's chroma components is included in the video region level, based on syntax flags indicating whether codec tools for processing different color components individually are enabled. In some embodiments, this syntax element is omitted when the luma and chroma samples of a block are not separated.

[0466] Figure 15 This is a flowchart representation of a video processing method 1500 according to the present technology. Method 1500 includes, in operation 1510, performing a conversion between video blocks and the video bitstream according to a rule specifying whether a syntax element identifying the deblocking offset of the video's chroma components is included at the video region level, based on syntax flags specifying the presence of parameters for the codec tools for the chroma components in the bitstream. In some embodiments, the syntax element is omitted where the syntax flags specify that the deblocking offset of the codec tools for the chroma components is omitted from the bitstream.

[0467] In some embodiments, when the syntax element is omitted from the signaling notification, the deblocking offset is inferred to be 0. In some embodiments, the deblocking offset applicable at the video region level includes at least one of the following: a first deblocking parameter offset (divided by 2) applied to β of the Cb component, wherein the first deblocking parameter is represented as cb_beta_offset_div2; a second deblocking parameter offset (divided by 2) applied to tC of the Cb component, wherein the second deblocking parameter is represented by cb_tc_offset_div2; a third deblocking parameter offset (divided by 2) applied to β of the Cr component, wherein the third deblocking parameter is represented by cr_beta_offset_div2; or a fourth deblocking parameter offset (divided by 2) applied to tC of the Cr component, wherein the fourth deblocking parameter is represented by cr_tc_offset_div2.

[0468] In some embodiments, the video region level includes a set of picture parameters. In some embodiments, the video region level includes a picture header. In some embodiments, the video region includes stripes. In some embodiments, syntax flags specifying the presence of parameters for encoding / decoding tools for chroma components in the bitstream also determine the presence of chroma quantization parameter offsets in the bitstream.

[0469] Figure 16This is a flowchart representation of a video processing method 1600 according to the present technology. Method 1600 includes, in operation 1610, performing a conversion between video blocks and the video bitstream according to a rule, wherein the rule specifies a syntax flag indicating whether chroma quantization parameter offsets are processed for the conversion, and also indicates whether deblocking offsets of the video chroma components are processed for the conversion.

[0470] In some embodiments, the syntax flags include pps_chroma_tool_params_present_flag. In some embodiments, the syntax flags include pps_chroma_tool_offsets_present_flag.

[0471] In some embodiments, the conversion includes encoding the video into a bitstream. In some embodiments, the conversion includes decoding the video from the bitstream.

[0472] In this document, the term "video processing" can refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm can be applied during the conversion from the pixel representation of a video to its corresponding bitstream representation, and vice versa. As defined in the syntax, the bitstream representation of the current video block can, for example, correspond to bits that are co-located or scattered at different positions within the bitstream. For example, a macroblock can be encoded based on the error residual values ​​from the transformation and encoding, and also using bits from the header and other fields in the bitstream.

[0473] The disclosed and other solutions, examples, embodiments, modules, and functional operations described in this application can be implemented in digital electronic circuits, or computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or combinations thereof. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible and non-volatile computer-readable medium for execution by a data processing apparatus or for controlling the operation of the data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a storage device, a material composition that influences machine-readable propagated signals, or one or more of these. The terms "data processing unit" or "data processing apparatus" include all means, devices, and machines for processing data, including, for example, programmable processors, computers, or multiprocessors or computer groups. In addition to hardware, the apparatus may also include code that creates an execution environment for a computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or combinations thereof. The propagated signals are artificially generated signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device.

[0474] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language (including compiled or interpreted languages) and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units 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 holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to that program, or in multiple coordinating files (e.g., a file storing one or more modules, subroutines, or portions of code). Computer programs can be deployed and executed on one or more computers located at a single site or distributed across multiple sites interconnected by a communication network.

[0475] The processes and logic flows described in this application can be executed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processes and logic flows can also be executed by special-purpose logic circuits, and the apparatus can also be implemented as special-purpose logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits).

[0476] For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as one or more of any type of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor that executes instructions and one or more storage devices that store the instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or receive data from or transfer data to one or more mass storage devices via operative coupling, or both. However, a computer does not necessarily have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable hard disks; magneto-optical disks; and CD-ROMs and DVD-ROMs. The processor and memory may be supplemented by or merged into special-purpose logic circuitry.

[0477] While this patent document contains numerous details, it should not be construed as limiting the scope of any invention or claim, but rather as a description of features of specific embodiments of a particular invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various functions described in the context of a single embodiment may also be implemented individually in multiple embodiments, or in any suitable sub-combination. Furthermore, although the foregoing features may be described as functioning in certain combinations, or even initially claimed to be so, in certain circumstances, one or more features from a combination of claims may be removed from the combination, and a combination of claims may refer to a sub-combination or a variation of a sub-combination.

[0478] Similarly, although the operations are described in a specific order in the accompanying drawings, this should not be construed as requiring the specific order or sequence shown to perform such operations, or all the described operations, in order to obtain the desired result. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.

[0479] Only some implementations and examples are described. Other implementations, enhancements and variations can be made based on the content described and illustrated in this patent document.

Claims

1. A method for processing video data, comprising: Perform the conversion between the video and the video bitstream according to the rules. The rule specifies that a first flag related to the encoding / decoding tool offset used for the chroma components is included in the Picture Parameter Set (PPS) in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the first set of syntax elements specifying the first chroma deblocking parameter offset is included in the PPS in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the second set of syntax elements for the second chroma deblocking parameter offset of the video image used for the video is included in the image header referencing the PPS. The rule further specifies whether the third set of syntax elements for determining the third chroma deblocking parameter offset of the stripe used for the video image is included in the stripe header referencing the PPS, based on the value of the first flag. The value of the first flag is related to the color format of the video image.

2. The method according to claim 1, wherein, The rule further specifies that the value of the first flag is used to determine whether to notify or parse the third chroma deblocking parameter offset at the strip level or a higher level of signaling.

3. The method according to claim 2, wherein, The rule further specifies that the third chroma deblocking parameter offset should be determined based on the value of the first flag.

4. The method according to claim 3, wherein, The rule further specifies that when the first flag has a first value and the third set of syntax elements does not exist, the third chroma deblocking parameter offset is notified or parsed at the image level signaling level.

5. The method according to claim 1, wherein, The rule further specifies that if the first flag has a second value, the first group of syntax elements, the second group of syntax elements, and the third group of syntax elements do not exist.

6. The method according to claim 5, wherein, When the first flag has the second value, it is not allowed to notify or parse the second chroma deblocking parameter offset for the video image and the third chroma deblocking parameter offset for the stripe at a higher level of signaling.

7. The method according to claim 6, wherein, When the first flag has the second value, notification or parsing of the second chroma deblocking parameter offset for the video image is not allowed at the PPS level, and notification or parsing of the third chroma deblocking parameter offset for the stripe is not allowed at the image level.

8. The method according to claim 7, wherein, When the first flag has the second value, the second chroma deblocking parameter offset for the video image is notified or parsed at the picture level, and the third chroma deblocking parameter offset for the strip is notified or parsed at the strip level.

9. The method according to claim 8, wherein, The rule further specifies whether the first group of syntax elements, the second group of syntax elements, and the third group of syntax elements are included in the bitstream, also based on the value of a second flag related to the application of the deblocking filter. The rule further specifies that, based on the value of the second flag, the first syntax element specifying the first luminance deblocking parameter offset is conditionally included in the PPS. The rule further specifies that, based on the value of the second flag, a second syntax element for the second luminance deblocking parameter offset of the video image is conditionally included in the image header referencing the PPS. The rule further specifies that, based on the value of the second flag, a third syntax element specifying the third luminance deblocking parameter offset for the strip is conditionally included in the strip header referencing the PPS.

10. The method according to claim 9, wherein, When the first flag has the second value, a signaling notification or parsing is made for a second chroma deblocking parameter offset for the video image based on a second syntax element specifying a second luminance deblocking parameter offset for the video image, and a signaling notification or parsing is made for a third chroma deblocking parameter offset for the strip based on a third syntax element specifying a third luminance deblocking parameter offset for the strip.

11. The method according to claim 1, wherein, The first group of syntax elements includes at least one of the following: pps_cb_beta_offset_div2, pps_cb_tc_offset_div2, pps_cr_beta_offset_div2 or pps_cr_tc_offset_div2; The second group of syntax elements includes at least one of the following: ph_cb_beta_offset_div2, ph_cb_tc_offset_div2, ph_cr_beta_offset_div2 or ph_cr_tc_offset_div2; The third group of syntax elements includes at least one of the following: sh_cb_beta_offset_div2, sh_cb_tc_offset_div2, sh_cr_beta_offset_div2 or sh_cr_tc_offset_div2.

12. The method according to claim 1, wherein, When the color format of the video image is 4:0:0, the first group of syntax elements, the second group of syntax elements, and the third group of syntax elements are omitted from the bitstream.

13. The method according to claim 1, wherein, The rule further specifies that the value of the first flag is used to determine whether a fourth set of syntax elements that specifies the offset associated with the colorimetric parameter is included in the PPS of the bitstream.

14. The method according to claim 13, wherein, The rule further specifies that, in the absence of the fourth group of syntax elements, the value of the fourth group of syntax elements is inferred to be equal to 0.

15. The method according to claim 13, wherein, When the color format of the video image is 4:0:0, the fourth set of syntax elements does not exist in the bitstream.

16. The method according to claim 1, wherein, The conversion includes encoding the video into the bitstream.

17. The method according to claim 1, wherein, The conversion includes decoding the video from the bitstream.

18. An apparatus for processing video data, comprising a processor and a non-transient memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to: Perform the conversion between the video and the video bitstream according to the rules. in, The rule specifies that a first flag related to the encoding / decoding tool offset used for the chroma component is included in the Picture Parameter Set (PPS) in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the first set of syntax elements specifying the first chroma deblocking parameter offset is included in the PPS in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the second set of syntax elements for the second chroma deblocking parameter offset of the video image used for the video is included in the image header referencing the PPS. The rule further specifies whether the third set of syntax elements for determining the third chroma deblocking parameter offset of the stripe used for the video image is included in the stripe header referencing the PPS, based on the value of the first flag. The value of the first flag is related to the color format of the video image.

19. A non-transitory computer-readable storage medium storing instructions that cause a processor to: Perform the conversion between the video and the video bitstream according to the rules. in, The rule specifies that a first flag related to the encoding / decoding tool offset used for the chroma component is included in the Picture Parameter Set (PPS) in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the first set of syntax elements specifying the first chroma deblocking parameter offset is included in the PPS in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the second set of syntax elements for the second chroma deblocking parameter offset of the video image used for the video is included in the image header referencing the PPS. The rule further specifies whether the third set of syntax elements for determining the third chroma deblocking parameter offset of the stripe used for the video image is included in the stripe header referencing the PPS, based on the value of the first flag. The value of the first flag is related to the color format of the video image.

20. A non-transitory computer-readable recording medium for storing a video bitstream generated by a method performed by a video processing apparatus, wherein the method comprises: Generate the video bitstream according to the rules. The rule specifies that a first flag related to the encoding / decoding tool offset used for the chroma components is included in the Picture Parameter Set (PPS) in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the first set of syntax elements specifying the first chroma deblocking parameter offset is included in the PPS in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the second set of syntax elements for the second chroma deblocking parameter offset of the video image used for the video is included in the image header referencing the PPS. The rule further specifies whether the third set of syntax elements for determining the third chroma deblocking parameter offset of the stripe used for the video image is included in the stripe header referencing the PPS, based on the value of the first flag. The value of the first flag is related to the color format of the video image.

21. A method for storing a video bitstream, comprising: Generate video bitstreams according to rules; as well as The bitstream is stored in a non-transitory computer-readable recording medium. The rule specifies that a first flag related to the encoding / decoding tool offset used for the chroma components is included in the Picture Parameter Set (PPS) in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the first set of syntax elements specifying the first chroma deblocking parameter offset is included in the PPS in the bitstream. The rule further specifies that, based on the value of the first flag, it determines whether the second set of syntax elements for the second chroma deblocking parameter offset of the video image used for the video is included in the image header referencing the PPS. The rule further specifies whether the third set of syntax elements for determining the third chroma deblocking parameter offset of the stripe used for the video image is included in the stripe header referencing the PPS, based on the value of the first flag. The value of the first flag is related to the color format of the video image.

Images