getIBCMergeCandidates() does not consider JVET_M0170_MRG_SHARELIST

[XiangLi]

JVET_M0170_MRG_SHARELIST was proposed to use shared merge list when CUs are small. JVET_M0483_IBC introduced a separated merge list for IBC. However, the separated IBC merge list construction does not consider JVET_M0170_MRG_SHARELIST such that a 4x4 CU may still have its own IBC merge list. It looks that JVET_M0170_MRG_SHARELIST should be applied to IBC merge list as well.

[XiangLi]

A merge request for a fix has been submitted ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/312

[wchien]

The motivation of shared list is to have one single merge list for an area of 32 pixels. With IBC being separated from regular merge, the shared list definition needs to be changed. that is the reason why M0170 is not integrated into M0483. In the worst case, there are two 4x4 CUs in 8x4 area, and one is regular merge and another is IBC merge. The modification proposed does alleviate the problem but it is still not fit into shared list concept perfectly. Maybe new proposals are needed to address this problem.

[XiangLi]

According to following meeting notes (dB version), it looks M0170 should also be applied to IBC merge. Did I miss anything? But on the other hand, yes, we will have two shared lists for IBC and regular merge in the worst case, which looks not the intention of M0170. I agree new proposal on fix is needed in next meeting.

Meeting notes:

• How to implement merge? Share same process as in regular MV merge, but disallow TMVP, 0 vector means unavailable as it is invalid
• Constraints to be implemented in bitstream, no invalid vectors, merge shall not be used if the merge candidate is invalid (out of range or 0)

[yuhan]

The HMVP for IBC mode haven't been considered in the fix. According to M0170, for IBC sharing list, HMVP should be applied. A merge request for has been submitted.

[XiangLi]

Second part of fix is in ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/merge_requests/320