﻿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@…
