id summary reporter owner description type status priority milestone component version resolution keywords cc 1477 merge candidates rounding in SCM inconsistent with spec libin "The bug was originally reported by Marie-Pierre (marie-pierre.gallasso@allegrodvt.com) and some comments were from Rajan Joshi (rajanj@qti.qualcomm.com) In the specification text, in paragraph 8.5.3.2.2 Derivation process for luma motion vectors for merge mode, from step 1 to step 8, the merging candidates list is constructed without considering the value of use_integer_mv_flag. In step 9, the motion vector of candidate pointed by merge_idx is rounded if use_integer_mv_flag is equal to 1 before assignment to the current block. In HM, the motion vector of each candidate is rounded when use_integer_mv_flag is equal to 1, even the motion vector of the temporal candidate. So it can make a difference in 8.5.3.2.4 Derivation process for combined bi-predictive merging candidates, because in specification text, rounded and not rounded motion vectors may be combined. In function getInterMergeCandidate() in TComDataCu.ccp (line 2631), merge candidates are derived one-by-one. When use_integer_mv flag is 1 or when the reference picture is the current picture, each candidate is converted to integer pel before storing it in pcMvFieldNeighbours. When processing the next merge candidate, there is a pruning step that checks whether the newly derived merge candidate is identical to an earlier one. This is accomplished using the function call hasEqualMotion(). if ( isAvailableB1 && (!isAvailableA1 || !pcCULeft->hasEqualMotion( uiLeftPartIdx, pcCUAbove, uiAbovePartIdx ) ) ) The function hasEqualMotion() uses the original (non-rounded) motion vectors for comparison. So far, this behavior is exactly as in the spec, except that on the decoder side, there are a few mv rounding operations for unselected merge candidates, which has no normative impact. But later on, in case of bi-predictive merge, when selecting the combined merge candidates, there is a check for identical L0 and L1 motion vectors: if (iRefPOCL0 == iRefPOCL1 && pcMvFieldNeighbours[(uiArrayAddr<<1)].getMv() == pcMvFieldNeighbours[(uiArrayAddr<<1)+1].getMv()) Here the check is performed on rounded motion vectors instead of original ones. Thus the software behaves inconsistently. " defect closed major HM SCC SCC-7.0 (HM16.8) fixed marie-pierre.gallasso@… rajanj@… jct-vc@…