Opened 3 months ago

Closed 7 days ago

#438 closed defect (fixed)

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

Reported by: bheng Owned by:
Priority: minor Milestone:
Component: spec Version: VVC D6 vE
Keywords: Cc: ksuehring, bbross, XiangLi, fbossen, jvet@…

Description

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

Change history (12)

comment:1 Changed 3 months ago by bheng

  • Summary changed from JVET-O0650 - Chroma QP Signalling - handling of delta_qp_out_val = 0 to JVET-O0650 - Chroma QP Signalling - handling of delta_qp_in_val_minus1 = 0

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.

comment:2 Changed 6 weeks ago by 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.

comment:3 Changed 6 weeks ago by delagrangep

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

comment:4 Changed 6 weeks ago by 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.


comment:5 Changed 6 weeks ago by 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.


comment:6 Changed 6 weeks ago by 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.

comment:7 Changed 6 weeks ago by 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.

comment:8 Changed 6 weeks ago by 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.

comment:9 Changed 6 weeks ago by taoranlu

Sure, thanks for clarification.

comment:11 Changed 7 days ago by bbross

Thanks for reporting.

This is fixed in JVET-P2001-v8.

comment:12 Changed 7 days ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.