Opened 5 years ago
Closed 5 years ago
#756 closed defect (fixed)
Wrong increment in merge IBC
| Reported by: | pierrick.bouvier | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | VTM | Version: | |
| Keywords: | Cc: | ksuehring, XiangLi, fbossen, jvet@… |
Description
Increment is badly positioned when adding (0,0) motion vector to complete list of candidates after selecting history-based candidates.
It results in last candidate having value (0,0) (luckily), but wrong refIdx (set to -1), because it was semantically not initialized.
Merge requested attached:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/1174
Change history (3)
comment:1 follow-up: ↓ 2 Changed 5 years ago by pierrick.bouvier
comment:2 in reply to: ↑ 1 Changed 5 years ago by pierrick.bouvier
Replying to pierrick.bouvier:
More details on this bug:
ERROR found: "invalid block vector for IBC detected.", because another block vector was chosen instead of expected one.
In function getIBCMergeCandidates (source/Lib/CommonLib/UnitTools.cpp:725), candidates to IBC are added in following order:
1) Candidate A (left)
2) Candidate B (above)
3) Historical candidates (those contained in motionLut.lutIbc)
4) (0, 0) candidates added until we have enough candidates
Bug is found in section 4) (line 849).
The latest candidate to be added is not initialized (because of incrementation before return condition). It has value (0, 0) (which is ok) but its refIdx is still invalid (-1), when we expect (MAX_NUM_REF), as it is the case for other ones.
After that, IBC derivation may occur, until the historical candidates must be updated with selected block vector. In this case, and if the block vector used has a bad refIdx, we will have an incorrect historical candidates list.
Bug is subtle because it is triggered only after a sequence of multiple IBC merges.
However, you can see that variable cnt++ is always incremented *after* return conditions in all getIBCMergeCandidates function.
comment:3 Changed 5 years ago by fbarbier
- Resolution set to fixed
- Status changed from new to closed
More details on this bug:
In function getIBCMergeCandidates (source/Lib/CommonLib/UnitTools.cpp:725), candidates to IBC are added in following order:
1) Candidate A (left)
2) Candidate B (above)
3) Historical candidates (those contained in motionLut.lutIbc)
4) (0, 0) candidates added until we have enough candidates
Bug is found in section 4) (line 849).
The latest candidate to be added is not initialized (because of incrementation before return condition). It has value (0, 0) (which is ok) but it's refIdx is still invalid (-1), when we expect (MAX_NUM_REF), as it is the case for other ones.
After that, IBC derivation may occur, until the historical candidates must be updated with selected block vector. In this case, and if the block vector used has a bad refIdx, we will have an incorrect historical candidates list.
Bug is subtle because it is triggered only after a sequence of multiple IBC merges.
However, you can see that variable cnt++ is always incremented *after* return conditions in all getIBCMergeCandidates function.