JVET-O0650 - Chroma QP Signalling - handling of delta_qp_in_val_minus1 = 0

[bheng]

For chroma QP signalling tables, it seems like the case of delta_qp_out_val = 0 is not handled well.

My understanding is that the output QP table for such intervals should be flat and that the following QP step term should always be 0.

( delta_qp_out_val[ i ][j + 1] * m + sh ) / ( delta_qp_in_val_minus1[ i ][j + 1] + 1 )

However, with the rounding offset:

sh = ( delta_qp_in_val_minus1[ i ][j + 1 ] + 2 ) >> 1

Even values of delta_qp_in_val result in a constant step of +1. This can cause supposedly flat regions to grow linearly beyond the next qpOutVal pivot point, and can cause misalignment with pivot points and potentially out of range QP values.

I would suggest modifying the rounding offset to:

sh = ( delta_qp_in_val_minus1[ i ][j + 1 ] + 1 ) >> 1

[bheng]

Correction: I believe it is only a problem when delta_qp_in_val_minus1 = 0. But in any case, the suggested modification is the same.

[bbross]

Thanks for bringing that up. In order to address this issue, I would need:
a) the proponents of chroma mapping tables JVET-O0650 as well as other experts familiar with it to confirm the issue and the proposed fix.
b) to know whether VTM needs to be fixe as well in order to avoid mismatches.

[delagrangep]

I confirm the issue, and agree with the fix (+1 instead of +2).
Yes, VTM needs to fix too.

[fbossen]

As far as I can tell, this comes down to a basic math issue:

When computing a/b with rounding, one should compute (a+b/2)/b (assuming positive a and b). Currently the text and VTM compute (a+(b+1)/2)/b, which is bad, in particular when b is 1 (since you end up with a+1 instead of a).

This should definitely be corrected.

On the VTM side of things, both code and cfg files would need to be modified.

[taoranlu]

It looks the reason in current spec and VTM software to use sh = ( delta_qp_in_val_minus1[ i ][j + 1 ] + 2 ) >> 1
is that the variable delta_qp_in_val_minus1 is minus 1, so it should add 1 to get back to the delta of input values, which suggest current sh calculation is indeed doing (a + b/2)/2. (as b is delta_qp_in_val_minus1 + 1). For b>1 cases, it looks like the sh is correct.

For b=1 (so b-1 = 0) cases, it indeed causes issue as pointed out by Brian. How about a fix like this:
sh = delta_qp_in_val_minus1[ i ][j + 1 ] == 0 ? 0 : ( delta_qp_in_val_minus1[ i ][j + 1 ] + 2 ) >> 1

This fix will not need to change current CTC/cfg then.

[delagrangep]

Let's just do the right thing (+1). The misconception comes from unneeded rounding of rounding offset: denom should be divided by 2 and truncated.
I do not see a good reason to introduce normative complications to avoid revisiting cfg for the same result (same CTCs, actually).
I think Frank has already done the job for cfg files since JVET-O1166 used the correct rounding.

[taoranlu]

I'm fine with both options, just want to make sure if the changing of CTC coding results is the expected output if using +1 fix, since we modified rounding, the interpolated QPc mapping table will change slightly and cause chroma coding QP slightly different at some points.

For example, if we still use the current CTC cfg parameters to specify input and output QPvalues, the derived table for AI and HDR H1/H2 will have slight difference after fix +2 with +1.

[fbossen]

We don't want to change the coding results, which is why the cfg files need to be slightly modified when fixing the rounding in the code. Not a difficult thing to do.

[taoranlu]

Sure, thanks for clarification.

[fbossen]

A merge request was submitted:
​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/953

[bbross]

Thanks for reporting.

This is fixed in JVET-P2001-v8.