Wrong increment in merge IBC

[pierrick.bouvier]

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

[pierrick.bouvier]

More details on this bug:

ERROR found: "invalid block vector for IBC detected.", when it is correct.

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.

[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.