Filter parameter signaling in video picture header

Abstract

Methods and apparatus for video processing are described. Video processing may include video encoding, video decoding, or video transcoding. An example video processing method includes performing conversion between a video picture of a video and a bitstream of the video. In response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component of one or more slices in the first video unit, and the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component of one or more slices in the first video unit.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is made in accordance with applicable patent laws and / or rules to timely claim priority to and the benefit of U.S. Provisional Patent Application No. US63 / 017,499, filed on April 29, 2020. The entire disclosure of the above application is incorporated herein by reference as a part of the disclosure of this application for all purposes specified by law. Technical Field

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

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

[0005] This document discloses techniques that may be used by video encoders and decoders for processing a coded representation of a video using control information useful for decoding the coded representation.

[0006] In one example aspect, a video processing method is disclosed. The method includes performing conversion between a video picture of a video and a bitstream of the video. The conversion includes performing a deblocking filtering operation, in which a deblocking filter is used to selectively filter at least some samples of a reconstructed video block, and parameters of the deblocking filter are indicated. In response to a first syntax element in a first video unit level and a second syntax element in a first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 for a chroma component of one or more slices in the first video unit, and the second syntax element specifying a deblocking parameter offset of tC divided by 2 for a chroma component of one or more slices in the first video unit. The rule specifies that (1) where the syntax flag indicates that the chroma tool offset is present in the picture parameter set, the first syntax element is equal to a third syntax element in the second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components associated with the second video unit, and (2) where the syntax flag indicates that the chroma tool offset is not present in the picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to luma components of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to luma components of one or more slices in the first video unit.

[0007] In one example aspect, a video processing method is disclosed. The method includes performing a conversion between a video including one or more video blocks and a codec representation of the video, wherein the conversion includes performing a deblocking filtering operation, in which a reconstructed video block is selectively filtered using a deblocking filter, parameters of the deblocking filter are signaled in the codec representation according to a format rule, wherein the format rule includes an inference rule, by which parameters of the deblocking filter for chroma components are inferred from the codec representation.

[0008] In yet another example aspect, a video encoder apparatus is disclosed. The video encoder includes a processor configured to implement the above method.

[0009] In yet another exemplary aspect, a video decoder apparatus is disclosed. The video decoder includes a processor configured to implement the above method.

[0010] In yet another example aspect, a computer readable medium having code stored thereon is disclosed. The code embodies one of the methods described herein in the form of processor executable code.

[0011] These and other features are described in this document. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a block diagram of an example video processing system.

[0013] Figure 2 is a block diagram of a video processing device.

[0014] Figure 3 is a flow chart of an example method of video processing.

[0015] Figure 4 is a block diagram illustrating a video encoding and decoding system according to some embodiments of the present disclosure.

[0016] Figure 5 is a block diagram illustrating an encoder according to some embodiments of the present disclosure.

[0017] Figure 6 is a block diagram illustrating a decoder according to some embodiments of the present disclosure.

[0018] Figure 7 is a flow chart of a method of video processing according to the present technology. DETAILED DESCRIPTION

[0019] The section headers used in this document are for ease of understanding and do not limit the applicability of the techniques and embodiments disclosed in each section to only that section. In addition, the use of H.266 terminology in some descriptions is only for ease of understanding and is not intended to limit the scope of the disclosed technology. Therefore, the technology described in this article is also applicable to other video codec protocols and designs.

[0020] 1. Overview

[0021] This document relates to video codec technology. Specifically, this document is about improvements to the signaling notification of deblocking parameters. These ideas can be applied alone or in various combinations to any video codec standard or non-standard video codec supporting multi-layer video codec, such as the Versatile Video Codec (VVC) under development.

[0022] 2. Abbreviations

[0023] ALF Adaptive Loop Filter

[0024] APS Adaptive Parameter Set

[0025] AU Access Unit

[0026] AUD Access Unit Delimiter

[0027] AVC Advanced Video Codec

[0028] CLVS Codec Layer Video Sequence

[0029] CPB Codec Picture Buffer

[0030] CRA Clean Random Access

[0031] CTU Codec Tree Unit

[0032] CVS codec video sequence

[0033] DCI decoding capability information

[0034] DPB Decoded Picture Buffer

[0035] DU Decoding Unit

[0036] EOB End of bitstream

[0037] EOS sequence end

[0038] GDR Gradual Decode Refresh

[0039] HEVC High Efficiency Video Codec

[0040] HRD Hypothetical Reference Decoder

[0041] IDR Instant Decode Refresh

[0042] JEM Joint Exploration Mode

[0043] LMCS Luminance Mapping with Chroma Scaling

[0044] MCTS Motion Constraint Episodes

[0045] NAL Network Abstraction Layer

[0046] OLS output layer set

[0047] PH Image Header

[0048] PPS Picture Parameter Set

[0049] PTL profile, tier and level

[0050] PU Picture Unit

[0051] RADL Random Access Decodable Preamble (Image)

[0052] RAP Random Access Point

[0053] RASL Random Access Skip Preamble (picture)

[0054] RBSP Raw Byte Sequence Payload

[0055] RPL Reference Image List

[0056] SAO Sample Adaptive Offset

[0057] SEI Supplemental Enhancement Information

[0058] SPS Sequence Parameter Set

[0059] STSA Stepwise Temporal Sublayer Access

[0060] SVC Scalable Video Codec

[0061] VCL video codec layer

[0062] VPS Video Parameter Set

[0063] VTM VVC test model

[0064] VUI Video Availability Information

[0065] VVC Multi-functional Video Codec

[0066] 3. Preliminary Discussion

[0067] Video codec standards have evolved primarily through the development of the well-known ITU-T and ISO / IEC standards. ITU-T developed H.261 and H.263, ISO / IEC developed MPEG-1 and MPEG-4 Visual, and the two organizations jointly developed the H.262 / MPEG-2 Video and H.264 / MPEG-4 Advanced Video Codec (AVC) and H.265 / HEV standards. Since H.262, video codec standards have been based on a hybrid video codec structure, which utilizes temporal prediction plus transform codec. In order to explore future video codec technologies beyond HEVC, VCEG and MPEG jointly established the Joint Video Exploration Team (JVET) in 2015. Since then, JVET has adopted a variety of new methods and put them into a reference software called the Joint Exploration Model (JEM). JVET meetings are held simultaneously every quarter, and the goal of the new codec standard is to reduce the bit rate by 50% compared to HEVC. The new video codec standard was officially named Versatile Video Coding (VVC) at the JVET meeting in April 2018, and the first version of the VVC Test Model (VTM) was also released at that time. Due to the continuous efforts to standardize VVC, new coding technologies are adopted into the VVC standard at each JVET meeting. The VVC working draft and the test model VTM are updated after each meeting. The VVC project is now aiming for technical completion (FDIS) at the July 2020 meeting.

[0068] Parameter Set

[0069] AVC, HEVC, and VVC specify parameter sets. Types of parameter sets include SPS, PPS, APS, and VPS. AVC, HEVC, and VVC all support SPS and PPS. VPS was introduced starting with HEVC, and is included in both HEVC and VVC. APS is not included in AVC or HEVC, but is included in the latest VVC draft text.

[0070] SPS is designed to carry sequence-level header information, and PPS is designed to carry picture-level header information that does not change often. With SPS and PPS, there is no need to repeat information that does not change often for each sequence or picture, so redundant signaling of this information can be avoided. In addition, the use of SPS and PPS enables out-of-band transmission of important header information, which not only avoids the need for redundant transmission but also improves fault tolerance.

[0071] VPS is introduced to carry sequence-level header information common to all layers in a multi-layer bitstream.

[0072] APS is introduced to carry picture-level information or slice-level information that requires considerable bits for encoding and decoding. APS can be shared by multiple pictures and there may be considerable different variations in a sequence.

[0073] 3.2 Slice Header and Picture Header in VVC

[0074] Similar to HEVC, the slice header of VVC conveys information about a specific slice, including slice address, slice type, slice QP, picture order count (POC) least significant bit (LSB), RPS and RPL information, weighted prediction parameters, loop filter parameters, entry offset of slices, and WPP, etc.

[0075] VVC introduces a picture header (PH), which contains header parameters for a specific picture. Each picture must have one or only one PH. The PH basically carries those parameters that would have been in the slice header if the PH had not been introduced, and each parameter has the same value for all slices of the picture. These include IRAP / GDR picture indication; inter-slice / intra-slice allowed flags; POC LSB (and optionally, POC MSB); information about RPL, deblocking, SAO, ALF, QP delta and weighted prediction; codec block partitioning information; virtual boundaries; co-located picture information, etc. It is often the case that each picture in the entire picture sequence contains only one slice. In order to allow for not having at least two NAL units for each picture in this case, the PH syntax structure is allowed to be included in the PH NAL unit or in the slice header.

[0076] In VVC, information about co-located pictures used for temporal motion vector prediction is signaled in a picture header or a slice header.

[0077] 3.3 Deblocking Filter in VVC

[0078] In VVC, the deblocking filter is applied to samples adjacent to CU, TU, and sub-block boundaries, except when the boundary is also a picture boundary, or when deblocking is disabled across a slice, slice, or sub-picture boundary (this is an option that can be signaled by the encoder). The deblocking filter process is applied to a 4x4 grid of CU boundaries and transform sub-block boundaries, and an 8x8 grid of prediction sub-block boundaries. The prediction sub-block boundaries include the prediction unit boundaries introduced by SbTMVP and affine modes, while the transform sub-block boundaries include the transform unit boundaries introduced by SBT and ISP modes, and the transform is due to the implicit partitioning of large CUs. As done in HEVC, the processing order of the deblocking filter is defined as first filtering the vertical edges of the entire picture horizontally, followed by filtering the horizontal edges vertically. This particular order enables multiple horizontal filtering or vertical filtering processes to be applied in parallel threads, or can still be implemented on a CTB-CTB basis, with only a small processing latency.

[0079] VVC specifies a long deblocking filter. The filtering process is similar to that in HEVC. The boundary filter strength (bS) of the deblocking filter is controlled by the values ​​of several syntax elements of two adjacent blocks, and two thresholds tC and β are determined from a predefined table based on the filter strength and the average quantization parameter of the adjacent blocks. For luma samples, one of the four cases of no filtering, weak filtering, short strong filtering, and long strong filtering is selected based on β and block size. There are three cases for chroma samples, no filtering, normal filtering, and strong filtering. Compared with HEVC, VVC newly introduces long strong filtering for luma samples and strong filtering for chroma samples. When the samples on either side of the boundary belong to a large block, a long luma strong filter is used. Samples belonging to a large block are defined as when the width for a vertical edge is greater than or equal to 32, or when the height for a horizontal edge is greater than or equal to 32. Up to 7 samples on one side of the boundary are filtered in the strong filter. When both sides of a chroma edge are greater than or equal to 8 (in units of chroma samples), strong chroma filtering is applied and 3 chroma samples from each side are filtered.

[0080] Luma adaptive deblocking in VVC further adjusts the tC and β of the deblocking filter based on the average luma level of the reconstructed samples. When luma adaptive deblocking is enabled, the offset qpOffset derived based on the average luma level around the filter boundary is added to the average quantization parameter of the two neighboring blocks. The mapping function of qpOffset and luma level should be derived from the transfer characteristics of the video content (Electronic-Optical Transfer Function (EOTF) and Optical-Optical Transfer Function (OOTF)) and signaled in the SPS.

[0081] 3.4 Deblocking Signaling in VVC

[0082] Deblocking signaling in some embodiments is defined as follows.

[0083] 7.3.2.4 Picture parameter set RBSP syntax

[0084]

[0085] 7.4.3.4 Picture parameter set RBSP semantics ......

[0086] deblocking_filter_control_present_flag equal to 1 specifies the presence of a deblocking filter control syntax element in the PPS. deblocking_filter_control_present_flag equal to 0 specifies the absence of a deblocking filter control syntax element in the PPS and specifies that the deblocking filter is applied to all slices referencing the PPS using a zero value deblocking β and tC offset.

[0087] deblocking_filter_override_enabled_flag equal to 1 specifies the presence of ph_deblocking_filter_override_flag in the PH referencing the PPS, or the presence of slice_deblocking_filter_override_flag in the slice header referencing the PPS. deblocking_filter_override_enabled_flag equal to 0 specifies the absence of ph_deblocking_filter_override_flag in the PH referencing the PPS, or the absence of slice_deblocking_filter_override_flag in the slice header referencing the PPS. When absent, the value of deblocking_filter_override_enabled_flag is inferred to be equal to 0.

[0088] pps_deblocking_filter_disabled_flag equal to 1 specifies that deblocking filtering operations are not applied to slices that reference a PPS for which one of the following two conditions is true: 1) ph_deblockig_filter_disabled_flag and slice_deblocking_filter_disabled_flag are not present, and 2) ph_deblockig_filter_disabled_flag or slice_deblocking_filter_disabled_flag is present and equal to 1, and also specifies that deblocking filtering operations are applied to slices that reference a PPS for which ph_deblockig_filter_disabled_flag or slice_deblocking_filter_disabled_flag is present and equal to 0.

[0089] pps_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to slices that reference a PPS for which one of the following two conditions is true: 1) ph_deblockig_filter_disabled_flag and slice_deblocking_filter_disabled_flag are not present, and 2) ph_deblockig_filter_disabled_flag or slice_deblocking_filter_disabled_flag is present and equal to 0, and also specifies that the operation of the deblocking filter is not applied to slices that reference a PPS for which ph_deblockig_filter_disabled_flag or slice_deblocking_filter_disabled_flag is present and equal to 1.

[0090] When not present, the value of pps_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0091] dbf_info_in_ph_flag equal to 1 specifies that the deblocking filter information is present in the PH syntax structure and not in slice headers referencing a PPS that does not contain a PH syntax structure. dbf_info_in_ph_flag equal to 0 specifies that the deblocking filter information is not present in the PH syntax structure and may be present in slice headers referencing a PPS. When not present, the value of dbf_info_in_ph_flag is inferred to be equal to 0.

[0092] pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2 specify the default deblocking parameter offsets for β and tC (divided by 2) that are applied to the luma component of the slice referencing the PPS, unless the default deblocking parameter offsets are overridden by the deblocking parameter offsets present in the picture header or slice header of the slice referencing the PPS. The values ​​of pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2 are both inferred to be equal to 0.

[0093] pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2 specify the default deblocking parameter offsets for β and tC (divided by 2) that are applied to the Cb component of the slice referencing the PPS, unless the default deblocking parameter offsets are overridden by the deblocking parameter offsets present in the picture header or slice header of the slice referencing the PPS. The values ​​of pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2 are inferred to be equal to pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2, respectively.

[0094] pps_cr_beta_offset_div2 and pps_cr_tc_offset_div2 specify the default deblocking parameter offsets for β and tC (divided by 2) that are applied to the Cr component of the slice referencing the PPS, unless the default deblocking parameter offsets are overridden by the deblocking parameter offsets present in the picture header or slice header of the slice referencing the PPS. The values ​​of pps_cr_beta_offset_div2 and pps_cr_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of pps_cr_beta_offset_div2 and pps_cr_tc_offset_div2 are inferred to be equal to pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2, respectively. ......

[0095] 7.3.2.7 Picture header structure syntax

[0096]

[0097]

[0098] 7.4.3.7 Image header structure semantics

[0099] ph_deblocking_filter_override_flag equal to 1 specifies that deblocking parameters are present in PH. ph_deblocking_filter_override_flag equal to 0 specifies that deblocking parameters are not present in PH. When not present, the value of ph_deblocking_filter_override_flag is inferred to be equal to 0.

[0100] ph_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 1 or is present in the SH and is equal to 1, and also specifies that the operation of the deblocking filter is applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 0 or is present in the SH and is equal to 0.

[0101] ph_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 0 or is present in the SH and is equal to 0, and also specifies that the operation of the deblocking filter is not applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 1 or is present in the SH and is equal to 1.

[0102] When ph_deblocking_filter_disabled_flag is not present, it is inferred as follows:

[0103] If both pps_deblocking_filter_disabled_flag and ph_deblocking_filter_override_flag are equal to 1, the value of ph_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0104] Otherwise (pps_deblocking_filter_disabled_flag or ph_deblocking_filter_override_flag is equal to 0), the value of ph_deblocking_filter_disabled_flag is inferred to be equal to pps_deblocking_filter_disabled_flag.

[0105] ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the luma component of the slice associated with the PH. The values ​​of ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 are inferred to be equal to pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2, respectively.

[0106] ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cb component of the slice associated with the PH. The values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively.

[0107] ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cr components of the slices associated with the PH. The values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 should both be in the range of -12 to 12, inclusive. When not present, the values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively. ......

[0108] 7.3.7.1 General Strip Header Syntax

[0109]

[0110]

[0111] 7.4.8.1 General Strip Header Semantics

[0112] slice_deblocking_filter_override_flag equal to 1 specifies that the deblocking parameters are present in the slice header. slice_deblocking_filter_override_flag equal to 0 specifies that the deblocking parameters are not present in the slice header. When not present, the value of slice_deblocking_filter_override_flag is inferred to be equal to 0.

[0113] slice_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the current slice. slice_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the current slice.

[0114] When slice_deblocking_filter_disabled_flag is not present, it is inferred as follows:

[0115] - If pps_deblocking_filter_disabled_flag and slice_deblocking_filter_override_flag are both equal to 1, the value of slice_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0116] Otherwise (pps_deblocking_filter_disabled_flag or slice_deblocking_filter_override_flag is equal to 0), the value of slice_deblocking_filter_disabled_flag is inferred to be equal to ph_deblocking_filter_disabled_flag.

[0117] slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 specify the deblocking parameter offsets of beta and tc (divided by 2) that are applied to the luma components of the current slice. The values ​​of slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively.

[0118] slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 specify the deblocking parameter offsets of beta and tc (divided by 2) that are applied to the Cb component of the current slice. The values ​​of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively.

[0119] slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 specify the deblocking parameter offsets of beta and tc (divided by 2) that are applied to the Cr components of the current slice. The values ​​of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively.

[0120] 4. Technical problems solved by the disclosed technical solutions and embodiments

[0121] In some implementations, existing designs have the following problems:

[0122] 1) When not present, the inference of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 makes the values ​​of pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2 useless.

[0123] 2) When not present, the inference of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 makes the values ​​of pps_cr_beta_offset_div2 and pps_cr_tc_offset_div2 useless.

[0124] 3) When not present, the inference of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 makes the values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 useless.

[0125] 4) When not present, the inference of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 makes the values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 useless.

[0126] 5. Examples of solutions and implementation examples

[0127] To solve the above problems and other problems, the following summarized methods are disclosed. The present invention should be considered as an example to explain the general concept and should not be interpreted in a narrow way. In addition, these inventions can be applied individually or in any combination.

[0128] 1) To address issue 1, when not present, the inference of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 is changed as follows:

[0129] When not present, the values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 are inferred as follows. If pps_chroma_tool_offsets_present_flag is equal to 0, then ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively. Otherwise, ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 are inferred to be equal to pps_cb_beta_offset_div2 and pps_cb_tc_offset_div2, respectively.

[0130] 2) To address issue 2, when not present, the inference of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 is changed as follows:

[0131] When not present, the values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 are inferred as follows: If pps_chroma_tool_offsets_present_flag is equal to 0, then ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively. Otherwise, ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 are inferred to be equal to pps_cr_beta_offset_div2 and pps_cr_tc_offset_div2, respectively.

[0132] 3) To address issue 3, when not present, the inference of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 is changed as follows:

[0133] When not present, the values ​​of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 are inferred as follows. If pps_chroma_tool_offsets_present_flag is equal to 0, slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively. Otherwise, slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 are inferred to be equal to ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2, respectively.

[0134] 4) To address issue 4, when not present, the inference of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 is changed as follows:

[0135] When not present, the values ​​of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 are inferred as follows. If pps_chroma_tool_offsets_present_flag is equal to 0, then slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively. Otherwise, slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 are inferred to be equal to ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2, respectively.

[0136] 6. Examples

[0137] The following are some example embodiments of some of the inventive aspects summarized in Section 5 above, which may be applied to the VVC specification. Most of the relevant parts added or modified are The parts are underlined, and some of the deleted parts are marked with [[ ]].

[0138] 6.1 First Embodiment

[0139] This embodiment is used for items 1, 2, 3 and 4.

[0140] 7.4.3.7 Image header structure semantics

[0141] ph_deblocking_filter_override_flag equal to 1 specifies that deblocking parameters are present in the PH. ph_deblocking_filter_override_flag equal to 0 indicates that deblocking parameters are not present in the PH. When not present, the value of ph_deblocking_filter_override_flag is inferred to be equal to 0.

[0142] ph_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 1, or is present in the SH and is equal to 1, and also specifies that the operation of the deblocking filter is applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is present in the SH and is inferred to be equal to 0, or is not present in the SH and is equal to 0.

[0143] ph_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 0 or is present in the SH and is equal to 0, and also specifies that the operation of the deblocking filter is not applied to the slices associated with the PH for which slice_deblocking_filter_disabled_flag is not present in the SH and is inferred to be equal to 1 or is present in the SH and is equal to 1.

[0144] When ph_deblocking_filter_disabled_flag is not present, it is inferred as follows:

[0145] If both pps_deblocking_filter_disabled_flag and ph_deblocking_filter_override_flag are equal to 1, the value of ph_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0146] Otherwise (pps_deblocking_filter_disabled_flag or ph_deblocking_filter_override_flag is equal to 0), the value of ph_deblocking_filter_disabled_flag is inferred to be equal to pps_deblocking_filter_disabled_flag.

[0147] ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the luma component of the slice associated with the PH. The values ​​of ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2 are inferred to be equal to pps_luma_beta_offset_div2 and pps_luma_tc_offset_div2, respectively.

[0148] ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cb component of the slice associated with the PH. The values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 should both be in the range of -12 to 12 (inclusive).

[0149]

[0150] [[When not present, the values ​​of ph_cb_beta_offset_div2 and ph_cb_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively. ]]

[0151] ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cr component of the slice associated with the PH. The values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 should both be in the range of -12 to 12 (inclusive).

[0152]

[0153] [[When not present, the values ​​of ph_cr_beta_offset_div2 and ph_cr_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively. ]] ......

[0154] 7.4.8.1 General Strip Header Semantics ......

[0155] slice_deblocking_filter_override_flag equal to 1 specifies that the deblocking parameters are present in the slice header. slice_deblocking_filter_override_flag equal to 0 specifies that the deblocking parameters are not present in the slice header. When not present, the value of slice_deblocking_filter_override_flag is inferred to be equal to 0.

[0156] slice_deblocking_filter_disabled_flag equal to 1 specifies that the operation of the deblocking filter is not applied to the current slice. slice_deblocking_filter_disabled_flag equal to 0 specifies that the operation of the deblocking filter is applied to the current slice.

[0157] When slice_deblocking_filter_disabled_flag is not present, it is inferred as follows:

[0158] - If pps_deblocking_filter_disabled_flag and slice_deblocking_filter_override_flag are both equal to 1, the value of slice_deblocking_filter_disabled_flag is inferred to be equal to 0.

[0159] Otherwise (pps_deblocking_filter_disabled_flag or slice_deblocking_filter_override_flag is equal to 0), the value of slice_deblocking_filter_disabled_flag is inferred to be equal to ph_deblocking_filter_disabled_flag.

[0160] slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 specify the deblocking parameter offsets of beta and tc (divided by 2) that are applied to the luma components of the current slice. The values ​​of slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 should both be in the range -12 to 12, inclusive. When not present, the values ​​of slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2 are inferred to be equal to ph_luma_beta_offset_div2 and ph_luma_tc_offset_div2, respectively.

[0161] slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cb component of the current slice. The values ​​of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 should both be in the range -12 to 12 (inclusive).

[0162]

[0163] [[When not present, the values ​​of slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively. ]]

[0164] slice_cb_beta_offset_div2 and slice_cb_tc_offset_div2 specify the deblocking parameter offsets of β and tC (divided by 2) that are applied to the Cr component of the current slice. The values ​​of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 should both be in the range -12 to 12 (inclusive).

[0165]

[0166] [[When not present, the values ​​of slice_cr_beta_offset_div2 and slice_cr_tc_offset_div2 are inferred to be equal to slice_luma_beta_offset_div2 and slice_luma_tc_offset_div2, respectively. ]]

[0167] Figure 1 1 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 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, a passive optical network (PON), and wireless interfaces such as Wi-Fi or a cellular interface.

[0168] System 1900 may include a codec component 1904 that can implement various codecs 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 generate a codec representation of the video. Codec technology is therefore sometimes referred to as video compression or video transcoding technology. The output of codec component 1904 can be stored or sent via a communication connection such as represented by component 1906. The bitstream (or codec) representation of the storage or communication transmission of the video received at input 1902 can be used by component 1908 to generate pixel values ​​or transmit to a displayable video of display interface 1910. The process of generating user-visible video from the bitstream representation is sometimes referred to as video decompression. In addition, although some video processing operations are referred to as "codec" operations or tools, it will be understood that the codec tool or operation is used at the encoder, and the corresponding decoding tool or operation of the inverse codec result will be performed by the decoder.

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

[0170] Figure 2 is a block diagram of a video processing device 3600. Device 3600 may be used to implement one or more methods described herein. Device 3600 may be embodied in a smartphone, a tablet, a computer, an Internet of Things (IoT) receiver, etc. Device 3600 may include one or more processors 3602, one or more memories 3604, and video processing hardware 3606. Processor(s) 3602 may be configured to implement one or more methods described in this document. Memory(s) 3604 may be used to store data and code for implementing the methods and techniques described herein. Video processing hardware 3606 may be used to implement some of the techniques described in this document in hardware circuitry.

[0171] Figure 4 is a block diagram illustrating an example video coding system 100 that may utilize the techniques of this disclosure.

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

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

[0174] The video source 112 may include a source, such as a video capture device, an interface for receiving video data from a video content provider, and / or a computer graphics system for generating video data, or a combination of these sources. The video data may include one or more pictures. The video encoder 114 encodes the video data from the video source 112 to generate a bit stream. The bit stream may include a bit sequence that forms a codec representation of the video data. The bit stream may include a codec picture and related data. The codec picture is a codec representation of the picture. Related data may include a sequence parameter set, a picture parameter set, and other grammatical structures. The I / O interface 116 may include a modulator / demodulator (modem) and / or a transmitter. The coded video data may be directly sent to the target device 120 via the network 130a via the I / O interface 116. The coded video data may also be stored on a storage medium / server 130b for access by the target device 120.

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

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

[0177] The video encoder 114 and the video decoder 124 may operate in accordance with a video compression standard, such as the High Efficiency Video Codec (HEVC) standard, the Versatile Video Codec (VVC) standard, and other current and / or additional standards.

[0178] Figure 5 is a block diagram showing an example of a video encoder 200, which may be Figure 4 The video encoder 114 in the system 100 is shown.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0202] Figure 6 is a block diagram showing an example of a video decoder 300, which may be Figure 4 The video decoder 124 in the system 100 is shown.

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

[0204] exist Figure 6 In the example of FIG. 3 , the video decoder 300 includes an entropy decoding unit 301, a motion compensation unit 302, an intra-frame prediction unit 303, an inverse quantization unit 304, an inverse transform unit 305, a reconstruction unit 306, and a buffer 307. In some examples, the video decoder 300 may perform operations generally similar to those for the video encoder 200 ( Figure 5 ) is the reverse of the encoding process described in .

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

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

[0207] The motion compensation unit 302 may calculate interpolation of sub-integer pixels of the reference block using an interpolation filter as used by the video encoder 200 during encoding of the video block. The motion compensation unit 302 may determine the interpolation filter used by the video encoder 200 based on received syntax information and use the interpolation filter to generate a prediction block.

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

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

[0210] The reconstruction unit 306 may add the residual block to the corresponding prediction block generated by the motion compensation unit 302 or the intra prediction unit 303 to form a decoded block. If necessary, a deblocking filter may also be applied to filter the decoded block to remove blocking artifacts. The decoded video block is then stored in a buffer 307 to provide a reference block for subsequent motion compensation / intra prediction and also to generate a decoded video for presentation on a display device.

[0211] The following provides some examples of preferred solutions of the embodiments.

[0212] The following solutions illustrate example embodiments of the techniques discussed in the previous sections (eg, items 1-4).

[0213] 1. A video processing method (eg, Figure 3 The method 3000 shown in the figure comprises performing (3002) a conversion between a video comprising one or more video blocks and a codec representation of the video; wherein the conversion comprises performing a deblocking filtering operation, in which a reconstructed video block is selectively filtered using a deblocking filter, and parameters of the deblocking filter are signaled in the codec representation according to a format rule, wherein the format rule comprises an inference rule, by which parameters of the deblocking filter for chroma components are inferred from the codec representation.

[0214] 2. The method of solution 1, wherein the chrominance component is a cr component.

[0215] 3. The method of any one of solutions 1-2, wherein the chrominance component is a cb component.

[0216] 4. The method of any one of solutions 1-3, wherein the inference rule specifies that the beta parameter for the deblocking filter and the offset parameter for the deblocking filter are inferred based on the value of a flag included in the codec representation.

[0217] 5. The method of solution 4, wherein the inference rule specifies that for a first value of the flag, the beta parameter and the offset parameter are inferred to be zero.

[0218] 6. The method of any of solutions 4-5, wherein the inference rule specifies that, for a second value of the flag, the beta parameter and the offset parameter are derived from the beta parameter and the offset parameter of the corresponding luminance block.

[0219] 7. The method of any one of solutions 1 to 6, wherein the conversion comprises encoding the video into a codec representation.

[0220] 8. The method of any one of solutions 1 to 6, wherein the conversion comprises decoding the codec representation to generate pixel values ​​of the video.

[0221] 9. A video decoding device, comprising a processor configured to implement the method stated in one or more of solutions 1 to 8.

[0222] 10. A video encoding device comprising a processor configured to implement the method set forth in one or more of solutions 1 to 8.

[0223] 11. A computer program product having computer code stored thereon, which, when executed by a processor, causes the processor to implement the method set forth in any one of solutions 1 to 8.

[0224] 12. The methods, apparatus, or systems described in this document.

[0225] Figure 77 is a flow chart of a video processing method 700 according to the present technology. The method 700 includes, at operation 710, performing conversion between a video picture of a video and a bitstream of the video. The conversion includes performing a deblocking filtering operation, in which at least some samples of a reconstructed video block are selectively filtered using a deblocking filter, and parameters of the deblocking filter are indicated. In response to a first syntax element in a first video unit level and a second syntax element in a first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component of one or more slices in the first video unit, and the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component of one or more slices in the first video unit. The rule specifies that: (1) where the syntax flag indicates that the chroma tool offset is present in the picture parameter set, the first syntax element is equal to a third syntax element in the second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components associated with the second video unit, and (2) where the syntax flag indicates that the chroma tool offset is not present in the picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to luma components of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to luma components of one or more slices in the first video unit.

[0226] In some embodiments, the chroma component is a cb component. In some embodiments, the chroma component is a cr component. In some embodiments, the first video unit level is a picture header and the second video unit level is a picture parameter set. In some embodiments, the first video unit is a picture and the second video unit includes one or more pictures. In some embodiments, the first video unit level is a slice header and the second video unit level is a picture header. In some embodiments, the first video unit is a slice and the second video unit is a picture.

[0227] In some embodiments, responsive to the chroma tool offset being present in the picture parameter set, the syntax flag is equal to 1. In some embodiments, responsive to the chroma tool offset being omitted in the picture parameter set, the syntax flag is equal to 0.

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

[0229] In this document, the term "video processing" may refer to video encoding, video decoding, video compression, or video decompression. For example, a video compression algorithm may be applied during the conversion from a pixel representation of a video to a corresponding bitstream representation, or vice versa. As defined by the syntax, the bitstream representation of the current video block may correspond, for example, to bits that are co-located or dispersed in different positions within the bitstream. For example, a macroblock may be encoded based on a transformed and coded error residual value and also using bits in a header and other fields in the bitstream. In addition, during the conversion, the decoder may parse the bitstream based on this determination, knowing that some fields may or may not exist, as described in the above solution. Similarly, the encoder may determine whether to include or not include certain syntax fields, and generate a codec representation accordingly by including or excluding syntax fields in the codec representation.

[0230] The disclosed and other solutions, examples, embodiments, modules and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware or hardware (including the structures disclosed in this document and their structural equivalents), or in a combination of one or more of them. 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 computer-readable medium, which are used to be run by a data processing device or control the operation of the data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances that affect machine-readable propagation signals, or a combination of one or more of them. The term "data processing device" includes all devices, equipment and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the device may also include code that creates an operating environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagation signal is an artificially generated signal generated to encode information for transmission to a suitable receiver device, for example, a machine-generated electrical signal, an optical signal, or an electromagnetic signal.

[0231] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language (including compiled or interpreted languages), and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may 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 the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions). A computer program may be deployed to run on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0232] The processes and logic flows described in this document can be performed by one or more programmable processors running one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed 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).

[0233] Processors suitable for running computer programs include, for example, general-purpose and special-purpose microprocessors, and any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operably coupled to receive data from or transfer data to or from the one or more mass storage devices. However, a computer does not require such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into a dedicated logic circuit.

[0234] Although this patent document contains many details, these details should not be interpreted as limitations on any subject matter or the scope of possible protection, but as descriptions of features of specific embodiments specified for specific technologies. Certain features described in the context of separate embodiments in this patent document may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments or in any suitable sub-combination, respectively. In addition, although features may be described above as working in certain combinations and even initially claimed as such, one or more features from the claimed combination may be excluded from the combination in some cases, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0235] Similarly, although operations are depicted in a particular order in the drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed, to achieve the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

[0236] Only a few implementations and examples are described, and other implementations, enhancements, and variations may be made based on what is described and shown in this patent document.

Claims

1. A video processing method, comprising: performing conversion between video pictures of a video and a bitstream of said video, wherein the converting comprises performing a deblocking filtering operation in which at least some samples of the reconstructed video block are selectively filtered using a deblocking filter, parameters of the deblocking filter being indicated, and wherein, in response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components of one or more slices in the first video unit, the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components of one or more slices in the first video unit, wherein the rule specifies that (1) where a syntax flag indicates that a chroma tool offset is present in a picture parameter set, the first syntax element is equal to a third syntax element in a second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component associated with the second video unit, and (2) where the syntax flag indicates that a chroma tool offset is not present in a picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to a luma component of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a luma component of one or more slices in the first video unit.

2. The method according to claim 1, wherein: The chrominance component is the cb component.

3. The method according to claim 1, wherein: The chrominance component is a cr component.

4. The method according to claim 1, wherein: The first video unit level is a picture header, and wherein the second video unit level is a picture parameter set.

5. The method according to claim 4, wherein: The first syntax element specifies a deblocking parameter offset of β divided by 2 applied to chroma components of a slice in a current picture, and the second syntax element specifies a deblocking parameter offset of tC divided by 2 applied to chroma components of a slice in the current picture.

6. The method according to claim 4, wherein: The first video unit is a picture, and wherein the second video unit includes one or more pictures.

7. The method according to claim 1, wherein: The first video unit level is a slice header, and wherein the second video unit level is a picture header.

8. The method according to claim 7, wherein: The first video unit is a slice, and wherein the second video unit is a picture.

9. The method according to claim 7, wherein: The first syntax element specifies a deblocking parameter offset of β divided by 2 applied to chroma components of a current slice, and the second syntax element specifies a deblocking parameter offset of tC divided by 2 applied to chroma components of the current slice.

10. The method according to claim 1, wherein: In response to the chroma tool offset being present in the picture parameter set, the syntax flag is equal to 1.

11. The method according to claim 1, wherein: In response to the chroma tool offset being omitted in the picture parameter set, the syntax flag is equal to 0.

12. The method according to any one of claims 1 to 11, wherein: The converting includes encoding the video into the bitstream.

13. The method according to any one of claims 1 to 11, wherein: The converting includes decoding the video from the bitstream.

14. A method for storing a bit stream of a video, comprising: generating a bitstream of the video from video pictures of the video, wherein the generating comprises performing a deblocking filtering operation in which at least some samples of the reconstructed video block are selectively filtered using a deblocking filter, parameters of the deblocking filter being indicated, and wherein, in response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components of one or more slices in the first video unit, the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components of one or more slices in the first video unit, wherein the rule specifies that (1) where a syntax flag indicates that a chroma tool offset is present in a picture parameter set, the first syntax element is equal to a third syntax element in a second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component associated with the second video unit, and (2) where the syntax flag indicates that a chroma tool offset is not present in the picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to a luma component of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a luma component of one or more slices in the first video unit.

15. An apparatus for processing video data, comprising a processor and a non-transitory memory having instructions thereon, wherein the instructions, when executed by the processor, cause the processor to: performing conversion between video pictures of a video and a bitstream of said video, in, The converting includes performing a deblocking filtering operation in which at least some samples of the reconstructed video block are selectively filtered using a deblocking filter, parameters of the deblocking filter being indicated, and wherein, in response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components of one or more slices in the first video unit, the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components of one or more slices in the first video unit, wherein the rule specifies that (1) where a syntax flag indicates that a chroma tool offset is present in a picture parameter set, the first syntax element is equal to a third syntax element in a second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component associated with the second video unit, and (2) where the syntax flag indicates that a chroma tool offset is not present in a picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to a luma component of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a luma component of one or more slices in the first video unit.

16. A non-transitory computer-readable storage medium storing instructions that cause a processor to: performing conversion between video pictures of a video and a bitstream of said video, in, The converting includes performing a deblocking filtering operation in which at least some samples of the reconstructed video block are selectively filtered using a deblocking filter, parameters of the deblocking filter being indicated, and wherein, in response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components of one or more slices in the first video unit, the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components of one or more slices in the first video unit, wherein the rule specifies that (1) where a syntax flag indicates that a chroma tool offset is present in a picture parameter set, the first syntax element is equal to a third syntax element in a second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component associated with the second video unit, and (2) where the syntax flag indicates that a chroma tool offset is not present in a picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to a luma component of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a luma component of one or more slices in the first video unit.

17. A video decoding device, comprising a processor configured to implement the method according to any one of claims 1 to 13.

18. A video encoding apparatus, comprising a processor configured to implement the method according to any one of claims 1 to 13.

19. A non-transitory computer-readable storage medium having stored thereon instructions, the instructions causing a processor to implement the method of any one of claims 1 to 13.

20. A non-transitory computer-readable recording medium storing a bit stream of a video generated by a method performed by a video processing device, wherein: The method comprises: generating a bitstream of the video from video pictures of the video, wherein the generating comprises performing a deblocking filtering operation in which at least some samples of the reconstructed video block are selectively filtered using a deblocking filter, parameters of the deblocking filter being indicated, and wherein, in response to a first syntax element in a first video unit level and a second syntax element in the first video unit level not being included in the bitstream, the first syntax element and the second syntax element are determined according to a rule, the first syntax element specifying a deblocking parameter offset of β divided by 2 applied to chroma components of one or more slices in the first video unit, the second syntax element specifying a deblocking parameter offset of tC divided by 2 applied to chroma components of one or more slices in the first video unit, wherein the rule specifies that (1) where a syntax flag indicates that a chroma tool offset is present in a picture parameter set, the first syntax element is equal to a third syntax element in a second video unit level, the third syntax element specifying a deblocking parameter offset of β divided by 2 applied to a chroma component associated with the second video unit, and the second syntax element is equal to a fourth syntax element in the second video unit level, the fourth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a chroma component associated with the second video unit, and (2) where the syntax flag indicates that a chroma tool offset is not present in the picture parameter set, the first syntax element is equal to a fifth syntax element in the first video unit level, the fifth syntax element specifying a deblocking parameter offset of β divided by 2 applied to a luma component of one or more slices in the first video unit, and the second syntax element is equal to a sixth syntax element in the first video unit level, the sixth syntax element specifying a deblocking parameter offset of tC divided by 2 applied to a luma component of one or more slices in the first video unit.

Images