Missing a default/inferred value for alf_cc_cb/cr_filters_signalled_minus1

[swong10]

The value of alf_cc_cb/cr_filters_signalled_minus1 Syntax Element shall be in the range of 0 to 3. It is used to parse alf_ctb_cc_cb/cr_idc[ ][ ].

If alf_cc_cb/cr_filter_signal_flag is set to 0, alf_cc_cb/cr_filters_signalled_minus1 is not present in the bitstream.

The VVC spec semantic does not provide an inferred or default value for alf_cc_cb/cr_filters_signalled_minus1. But in the VTM, it is effectively assumed a value of 3 when it is not present (i.e. alf_cc_cb/cr_filters_signalled = 3+1 = 4). Because there is a line in the following code segment (
ccAlfFilterCount[0] = ccAlfFilterCount[1] = MAX_NUM_CC_ALF_FILTERS; which is equal to 4). These 2 VTM variables are not inferred or defaulted to 0 as we would expect.

In AlfParameter.h:

struct CcAlfFilterParam
{
  bool    ccAlfFilterEnabled[2];
  bool    ccAlfFilterIdxEnabled[2][MAX_NUM_CC_ALF_FILTERS];
  uint8_t ccAlfFilterCount[2];
  short   ccAlfCoeff[2][MAX_NUM_CC_ALF_FILTERS][MAX_NUM_CC_ALF_CHROMA_COEFF];
  int     newCcAlfFilter[2];
  int     numberValidComponents;
  CcAlfFilterParam()
  {
    reset();
  }
  void reset()
  {
    std::memset( ccAlfFilterEnabled, false, sizeof( ccAlfFilterEnabled ) );
    std::memset( ccAlfFilterIdxEnabled, false, sizeof( ccAlfFilterIdxEnabled ) );
    std::memset( ccAlfCoeff, 0, sizeof( ccAlfCoeff ) );
    ccAlfFilterCount[0] = ccAlfFilterCount[1] = MAX_NUM_CC_ALF_FILTERS;
    numberValidComponents = 3;
    newCcAlfFilter[0] = newCcAlfFilter[1] = 0;
  }

The choice of this inferred/default value does affect the CABAC decoding of a bitstream that has alf_cc_cb/cr_filter_signal_flag set to 0.

Please confirm if this is a conformance case, and if a default/inferred value should be specified in the VVC spec to match that of the VTM?

[swong10]

There are couple related settings that have similar issues, which may be addressed together in this ticket as well.

There is also no default/inferred value for alf_chroma_num_alt_filters_minus1 and alf_luma_num_filters_signalled_minus1 when they are not present in the bitstream. The syntax element alf_chroma_num_alt_filters_minus is also used in CABAC decoding of alf_ctb_filter_alt_idx[ ][ ][ ].

But in the VTM (code segment pasted below), these two SE are effectively defaulted to 0 (i.e. alf_chroma_num_alt_filters = 0 + 1 = 1), when they are not present in the bitstream.

In AlfParameters.h:
struct AlfParam
{

void reset()
{

…
numAlternativesChroma = 1;
…
numLumaFilters = 1;
…

}

Thanks
Sam.

[fbossen]

I don't see a specification issue here.

I found alf_cc_cb_filters_signalled_minus1 used in one place: for the derivation of the CABAC context of alf_ctb_cc_cb_idc.

The parsing of alf_ctb_cc_cb_idc is conditioned on sh_alf_cc_cb_enabled_flag.

When sh_alf_cc_cb_enabled_flag is 1, sh_alf_cc_cb_aps_id is parsed. The semantics of sh_alf_cc_cb_aps_id state:

The value of alf_cc_cb_filter_signal_flag of the APS NAL unit having aps_params_type equal to ALF_APS and aps_adaptation_parameter_set_id equal to sh_alf_cc_cb_aps_id shall be equal to 1.

Thus, for valid bitstreams, when sh_alf_cc_cb_enabled_flag is 1, alf_cc_cb_filter_signal_flag is equal to 1.

When alf_cc_cb_filter_signal_flag is equal to 1, alf_cc_cb_filters_signalled_minus1 is defined.

Therefore, for valid bitstreams, alf_cc_cb_filters_signalled_minus1 is always defined when referenced for the parsing of alf_ctb_cc_cb_idc.

The behaviour for handling invalid bitstreams is not defined by the spec.

On the software side, it is generally good practice to initialize any variable, even if the variable may never be used. That doesn't make it a mismatch.