Wrong conditioning of sps_sign_data_hiding_enabled_flag in SPS

[bbross]

In SPS, the SDH flag is parsed conditioned on the DQ flag.

 sps_dep_quant_enabled_flag
  if( !sps_dep_quant_enabled_flag )
        sps_sign_data_hiding_enabled_flag

If not present, the SDH flag is inferred to be equal to 1:
In SH there is a similar condition:

   if( sps_dep_quant_enabled_flag )
         sh_dep_quant_enabled_flag
 if( sps_sign_data_hiding_enabled_flag   &&  !sh_dep_quant_enabled_flag )
        sh_sign_data_hiding_enabled_flag

At the Brussels meeting, it was decided to introduce that condition at the PH level (now SH) only, which makes sense.

"It was noted that dependent quantization can only be switched off at the PH level, whereas most coding tools can be disabled at a higher level. Decision (cleanup): Add an enable flag in the SPS, constrain the SPS flag according to the general_constraint flag, and condition the presence of the PH flag on the enable flag (and there are no other flags in other places). And do basically the same thing for sign data hiding. In the PH, don’t send the sign data hiding flag if the dependent quantization flag is 1."

The SPS conditioning was added by mistake during integration and should be removed in both spec and SW.

[jonathang]

To clarify:
Does this ticket assert that original design intention is reflected by replacing the SPS spec text

sps_dep_quant_enabled_flag
if( !sps_dep_quant_enabled_flag )
    sps_sign_data_hiding_enabled_flag

with

sps_dep_quant_enabled_flag
sps_sign_data_hiding_enabled_flag

[bbross]

Good point Jonathan, I forget to describe the fix and what you are suggesting is reflecting the original intent.
Thanks!

[bbross]

This will be fixed in JVET-S2001-v7.