The bug was originally reported by Marie-Pierre (marie-pierre.gallasso@…) and some comments were from Rajan Joshi (rajanj@…)

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.

According to 8.5.3.2 "Derivation process for motion vector components and reference indices" Intra Block Copy MVs can't cross tile boundaries (constrains (8-106)) but HM encoder in function TEncSearch::isBlockVectorValid() doesn't check this condition. Patch in attachment (to HM-16.15+SCM-8.4) can help to fix this problem.

According to 8.5.3.2 "Derivation process for motion vector components and reference indices" Intra Block Copy MVs can't cross tile boundaries (constrains (8-106)) but HM encoder in function TEncSearch::isBlockVectorValid() doesn't check this condition. Patch in attachment can help to fix this problem