JVET-O0162 Non-CE8: On IBC motion vector list construction [H. Chen, H. Yang (Huawei)]
In current VTM, a unified motion vector candidate list is used for IBC merge and MVP mode. According to the working draft JVET-N1001, when MaxNumMergeCand is set equal to 1, the length of MVP candidate list may be equal to 1 or 2, depending on the number of available spatial motion vector candidates. If mvp_l0_flag for the decoded IBC block is equal to 1, the motion vector for the IBC block may be undefined. Therefore, this contribution presents 3 methods to solve this issue. First method is to set the second candidate to be zero motion vector when MaxNumMergeCand is 1, which is aligned with the software. Second method is to infer mvp_l0_flag to 0 for IBC mode. Third method is to derive max(2, MaxNumMergeCand) candidates for IBC motion vector prediction.
The proposed method 2 reportedly shows 0.64%, 0.49% luma BD-rates for Class F in AI and RA settings, respectively, and shows 0.15%, 0.11% luma BD-rates for Class SCC in AI and RA settings, respectively.
The proposed method 3 reportedly shows -0.91%, -0.46% luma BD-rates for Class F in AI and RA settings, respectively, and shows -0.32%, -0.20% luma BD-rates for Class SCC in AI and RA settings, respectively, for Class SCC.
Currently, the software fills a zero vector as second candidate (which is then used as predictor), whereas the spec does not specify anything. Beyond the fact that the mismatch has to be resolved, this contribution indicates that the current SW approach may not be optimum.
Contributions 0331, 0480, 0574 also relate to this issue -> BoG.