JVET-R0480 AHG9: Restricted maximum numbers of ALF and CC-ALF filters [L. Zhang, Y.-K. Wang, K. Zhang, Z. Deng (Bytedance)] [late]

Was presented Thursday 23 April 1615

This contributions proposes the following aspects regarding restrictions of the maximum numbers of ALF and CC-ALF filters:

1. Replace the constraints on the number of ALF APSs with constraints on the number of filters, more specifically, the following constrain are proposed to be added:

The total number of adpative loop filter classes for luma component, the total number of alternative filters for chroma components, and the total number of cross-component filters in all APS NAL units for a PU shall be less than or equal to 200, 64, and 64, respectively.

1. On top of item 1), further change the coding of the APS ID in the APS syntax from u(5) to u(v), with the length being 9, 2, and 3, respectively for ALF, LMCS, and scaling list APSs, respectively.
2. On top of item 1), further change the coding of ALF APS indices and the number of ALF APSs in PH and SH from u(v) to ue(v).

In v2, the total number of adaptive loop filter classes for luma component in all APS NAL units for a PU is restricted to be less than or equal to 128 instead of 200.

It was commented that the proposal appears too flexible. The number of APS should be somewhat restricted, not be set to the maximum number of filters theoretically possible. Usage of ue(v) is also undesirable, could become quite large. It is furthermore not clear if there would not indeed be impact on low-level design (mapping table), and what the impact on the prediction would be.

Not clear what the benefit for coding efficiency would be, or if not even some overhead penalty might occur when the APSs come with low number of filters.

This proposed too much change at this late stage. It might introduce more issues than it solves, and needs further study.

No action was taken on this.

High level control of other tools (17)

Discussion started here in the JVET plenary on 19 April at 1415 UTC (chaired by GJS & JRO), and continued in JVET Thursday 23 Apr. at 1645 (chaired by JRO).

JVET-R0271 AHG9: High-level constraints of dependent quantization and sign data hiding [A. Nalci, M. Coban, M. Karczewicz (Qualcomm)]

This was initially reviewed in Track B on Saturday 18 April and was later moved here from section 5.3.1 since it is an HLS signalling issue. (There are other items in section 5.3.1 that are related, as the matter involves both high-level and low-level issues.)

In the 17^th JVET meeting, a slice level flag “slice_ts_residual_coding_disabled_flag” was adopted into VVC as part of JVET-Q0089 for lossless coding. This flag can bypass transform skip residual coding (TSRC) regardless of the residual type and transform or regular residual coding (RRC) is used for TS blocks. Since TS blocks can now be coded with RRC, dependent quantization (DQ) and sign data hiding (SDH) can introduce undesired behavior as pointed in Ticket #981, lossy results for lossless coding and potential coding loss. In this proposal several high-level aspects are proposed to alleviate this issue.

In variant #1, signalling of slice_ts_residual_coding_disabled_flag based on the picture level flags ph_dep_quant_enabled_flag and pic_sign_data_hiding_enabled_flag is disallowed such that, if either flag is 1 then TS blocks always use TSRC.

In variant #2, the picture header flags ph_dep_quant_enabled_flag and pic_sign_data_hiding_enabled_flag are first moved to slice header and signalling of slice level DQ and SDH flags are done depending on the slice_ts_residual_coding_disabled_flag. If slice_ts_residual_coding_disabled_flag=1 DQ and SDH flags are not signalled and inferred as 0.

In variant #3, the picture header flags ph_dep_quant_enabled_flag and pic_sign_data_hiding_enabled_flag are moved to slice header before slice_ts_residual_coding_disabled_flag and the signalling of slice_ts_residual_coding_disabled_flag are conditioned on these flags. In this case, if slice_ts_residual_coding_disabled_flag=0 then DQ and SDH are automatically turned off at the slice level.

In variant #4, picture header flags ph_dep_quant_enabled_flag and pic_sign_data_hiding_enabled_flag are moved to slice header (as in variant #2) however no signalling constraint is enforced. These tools can be turned off at the slice level (using config settings) to ensure lossless coding.

Variant #4 is identical with JVET-R0155 as presented.

Variant #3 is another option that was also mentioned in JVET-R0155 (but not presented).

Variant #1 is identical with JVET-R0153 aspect 2 method 2, and JVET-R0325

Variant #4 seems to be the most straightforward solution to resolve the coding efficiency problem of mixed lossy/lossless coding (where we don’t even know how severe that problem is). Definitely, there is nothing broken in the current spec, but software needs to be fixed wrt to DQ context derivation.

On the other hand, variant #3 (and also variant #2, which is spending 1 more bit in typical case) would at the same time resolve the issues brought in context of combining BDPCM and SDH. The same problem would probably exist when BDPCM was combined with DQ (which is not exercised in current software).

Decision (text/SW): Adopt JVET-R0271 variant #3

This also resolves the problem of text/software mismatch wrt to using DQ context derivation in TS/RRC coding.