Opened 6 weeks ago
Last modified 42 hours ago
#271 new defect
Motion vector rounding: tiny contradiction between N0335 integration and the meeting decision
Reported by: | tim.solovyev | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | spec | Version: | VVC D5 v9 |
Keywords: | Motion vector rounding, N0335, round toward zero | Cc: | ksuehring, bbross, XiangLi, fbossen, jvet@… |
Description
In Geneva it was decided to use rounding towards zero for motion vectors everywhere:
“…
N0085/N0335: unified MV rounding by setting the rounding offset to (1 << (shift – 1)) − 1 for rounding applied to an absolute value, to round toward zero.
Notes of Track B review:
- At the Macao meeting, based on JVET-L0377 we made the software match the text by rounding toward zero rather than toward minus infinity (at least for AMVR).
- Then at the Marrakech meeting, based on JVET-M0265, we tried to consistently apply rounding away from zero.
- Offset = 1 << (F-1);
- M= S >= 0 ? (S + Offset) >> F: -((-S + Offset) >> F).
- It was said that for deriving chroma vectors from luma vectors, it is necessary to round toward negative infinity for IBC to avoid a range problem. This is an exception.
- For temporal scaling in HEVC, it was said that we rounded toward zero. Some (tiny) gain was shown for doing that.
- Decision (consistency): Round MVs toward zero for MV rounding (incl. temporal scaling and spatial neighbour MV scaling and other cases if applicable). Use the software variation from M0335.
…“
In my understanding, according to the meeting notes, rounding should be performed as following:
- Offset = (1 << (F-1)) - 1;
- M= S >= 0 ? (S + Offset) >> F: -((-S + Offset) >> F).
It also corresponds to HEVC rounding in TMVP (that was mentioned in meeting notes), e.g.:
"mvLXCol = Clip3( −32768, 32767, Sign( distScaleFactor * mvCol ) * ( ( Abs( distScaleFactor * mvCol ) + 127 ) >> 8 ) ) (8-209)"
After N0335 integration Draft text have following (section 8.5.5.9 Derivation process for motion vector arrays from affine control point motion vectors):
- mvAvgLX[ 0 ] = ( mvAvgLX[ 0 ] + 1 − ( mvAvgLX[ 0 ] >= 0 ) ) >> 1 (8-713)
- mvAvgLX[ 1 ] = ( mvAvgLX[ 1 ] + 1 − ( mvAvgLX[ 1 ] >= 0 ) ) >> 1 (8-714)
It is another rounding method that was proposed in N0335, but not the method that was finally adopted, according to the meeting notes.
In my understanding, these formulas should look like:
- mvAvgLX[ 0 ] = mvAvgLX[ 0 ] >= 0 ? mvAvgLX[ 0 ] >> 1 : −( ( −mvAvgLX[ 0 ] ) >> 1 ) (8-713)
- mvAvgLX[ 1 ] = mvAvgLX[ 1 ] >= 0 ? mvAvgLX[ 1 ] >> 1 : −( ( −mvAvgLX[ 1 ] ) >> 1 ) (8-714)
Section 8.5.5.9 is not the only place with this problem. It is just one example.
This problem first occurs in VVC D5 v3.
Change history (5)
comment:1 Changed 6 weeks ago by tim.solovyev
comment:2 Changed 5 weeks ago by bbross
- Version changed from VVC D5 v5 to VVC D5 v6
comment:3 Changed 4 weeks ago by bbross
- Version changed from VVC D5 v6 to VVC D5 v7
comment:4 Changed 2 weeks ago by bbross
- Version changed from VVC D5 v7 to VVC D5 v8
comment:5 Changed 42 hours ago by bbross
- Version changed from VVC D5 v8 to VVC D5 v9
Of course, the results of two formulas could be bitexact (that's why I call the ticket "tiny contradiction"). The question here is which form is better for spec: with shift of negative value or without it?
E.g. for software, shift for negative value is not a good thing (due to behavior could be undefined or implementation-defined). For the spec, I'm not very sure, whether formula with shift of negative value is absolutely clear or not.