Replying to Tomohiro Ikai:
In software, in xAddVspCand() function, the VSP prediction list has already been set so that the bi-prediction never happens. Therefore, your proposed software change doesn't impact any results.

There seems to be a discrepancy between spec and software. The spec reads that bipred prevention is applied regardless of VSP flag:

14. When predFlagL0 is equal to 1 and predFlagL1 is equal to 1, and ( nOrigPbW + nOrigPbH ) is equal to 12, the following applies:

refIdxL1 = −1 (I 112)
predFlagL1 = 0 (I 113)

However, the software (in TDecEntropy.cpp and TEncSearch.cpp)disbles it in the case VSP flag is true as follows.
#if H_3D_VSP

if ( (pcCU->getInterDir(uiSubPartIdx) == 3) && pcSubCU->isBipredRestriction(uiPartIdx) && (pcCU\

->getVSPFlag(uiSubPartIdx) == 0))
#else

if ( (pcCU->getInterDir(uiSubPartIdx) == 3) && pcSubCU->isBipredRestriction(uiPartIdx) )

#endif

We should remove it (spec should be right).

In CTC and IBP(with MTK_I0072_IVARP_SCALING_FIX) experiment, there are no differences by this fix. No change is quite natural because VSP PU cannot be bi-prediction in the current specification. If looking at predFlagLXVSP setting logic(See I.8.5.3.2.13 Derivation process for a view synthesis prediction merge candidate), when predFlagL0VSP is 1, predFlagL1VSP cannot be 1. When predFlagL0VSP is 0, the PU is not bi-prediction. The same logic is applied in VSP inhericance case.

Lastly, even if VSP was able to be bi-prediction, we should prevent 8x4/4x8 bipred in VSP as well to preserve motion data storing implemenation.

Thanks for your comment. Correct, xAddVspCand() follows specification. So the reported part doesn't change the results but just just brings confusions. Thus clean up (removing) is appreciated.

Could you exactly specify which parts should be removed?

OK, the patch was attached.