Opened 14 months ago
Closed 4 weeks ago
#1618 closed defect (invalid)
[Multilayer Profiles] Potential Mismatch of VTM22.0 & Specification Related To Derivation Process For Merge Motion Vector Difference
Reported by: | ksthey | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | H.266/VVC v4 |
Component: | spec | Version: | H.266/VVC v3 |
Keywords: | Cc: | vzakharc, yuwenhe, jvet@… |
Description
In "8.5.2.7 Derivation process for merge motion vector difference", Equation 563:
mMvdL1[ 0 ] = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) ? mMvdL0[ 0 ] : −mMvdL0[ 0 ].
The equivalent code is in VTM22.0, InterPrediction.cpp, MergeCtx::getMmvdDeltaMv(), starting from line 2478:
if ((poc1 - currPoc)*(poc0 - currPoc) > 0)
{
}
else
{
deltaMv[1].set(-1 * deltaMv[0].getHor(), -1 * deltaMv[0].getVer());
}
According to specification, definition of Sign(x):
Sign(x) = 1; x > 0
Sign(x) = 0; x == 0
Sign(x) = -1; x < 0
Let's assume:
- result of condition below in specification as r_spec: r_spec = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 )
- result of condition below in VTM22.0 as r_vtm: r_vtm = (currPocDiffL1 * currPocDiffL0 > 0)
Use combination of currPocDiffL0 & currPocDiffL1 as input:
1.) (currPocDiffL0 < 0) && (currPocDiffL1 < 0)
r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm;
2.) (currPocDiffL0 < 0) && (currPocDiffL1 > 0)
r_spec = 0; r_vtm = 0; ==> r_spec == r_vtm;
3.) (currPocDiffL0 > 0) && (currPocDiffL1 < 0)
r_spec = 0; r_vtm = 0; ==> r_spec == r_vtm;
4.) (currPocDiffL0 < 0) && (currPocDiffL1 < 0)
r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm;
5.) (currPocDiffL0 == 0) && (currPocDiffL1 != 0)
r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm;
6.) (currPocDiffL0 != 0) && (currPocDiffL1 == 0)
r_spec = 1; r_vtm = 1; ==> r_spec == r_vtm;
7.) (currPocDiffL0 == 0) && (currPocDiffL1 == 0)
r_spec = 1; r_vtm = 0; ==> r_spec != r_vtm;
Case 5, 6 & 7 are only possible in multilayer profile (current picture and reference picture same POC, but different layers).
As shown above, for case 7, results of specification & VTM are different.
So, which is the correct one? specification or VTM?
Change history (6)
comment:1 Changed 14 months ago by ksthey
- Component changed from 360Lib to spec
comment:2 Changed 8 months ago by bbross
- Milestone set to H.266/VVC v4
- Version set to H.266/VVC v3
comment:3 Changed 4 weeks ago by fbossen
AFAICT, this came from proposal JVET-M0332, which included the following draft text (consistent with the software):
Otherwise, the following applies:
mMvdL0[ 0 ] = (currPocDiffL0*currPocDiffL1>0)?mMvdL1[ 0 ]: -mMvdL1[ 0 ];
mMvdL0[ 1 ] = (currPocDiffL0*currPocDiffL1>0)?mMvdL1[ 1 ]: -mMvdL1[ 1 ];
It was integrated in JVET-N1001v3 as:
Otherwise, the following applies:
mMvdL10[ 0 ] = Sign( currPocDiffL0 ) == Sign( currPocDiffL1 ) ? mMvdL1[ 0 ] : −mMvdL1[ 0 ] (8 375)
mMvdL0[ 1 ] = Sign( currPocDiffL0 ) == Sign( currPocDiffL1) ? mMvdL1[ 1 ] : −mMvdL1[ 1 ] (8 376)
Most likely, implications for multilayer were overlooked at the time and it would be difficult to claim that a particular behaviour was intended.
This issue needs to be resolved to address a ballot comment on VVC reference software.
comment:4 Changed 4 weeks ago by hmjang
Hi all,
I want to understand the issue on VTM regarding this.
the claimed case is the CASE7 ( currPocL0 == 0 and CurrPocL1 == 0).
at least this case looks like being gated by
"If currPocDiffL0 is equal to currPocDiffL1, the following applies" which is equation (548) above in the SPEC.
mMvdL0[ 0 ] = MmvdOffset[ xCb ][ yCb ][ 0 ] (548)
mMvdL0[ 1 ] = MmvdOffset[ xCb ][ yCb ][ 1 ] (549)
mMvdL1[ 0 ] = MmvdOffset[ xCb ][ yCb ][ 0 ] (550)
mMvdL1[ 1 ] = MmvdOffset[ xCb ][ yCb ][ 1 ] (551)
and also in the VTM, this part is same as shown below:
if ((poc0 - currPoc) == (poc1 - currPoc))
{
}
Do I miss something to understand issue?
comment:5 Changed 4 weeks ago by fbossen
@hmjang Thank you for pointing out the gating condition. I had missed that. So it looks like there is no mismatch after all because the "mismatched" condition is never reached in case 7.
comment:6 Changed 4 weeks ago by fbossen
- Resolution set to invalid
- Status changed from new to closed
Thanks for reporting and I see the mismatch for the multi-layer case. This should be fixed in v4 but before, we need to clarify which one is the intended behaviour.