Opened 4 years ago

Closed 4 years ago

#1477 closed defect (fixed)

merge candidates rounding in SCM inconsistent with spec

Reported by: libin Owned by:
Priority: major Milestone:
Component: HM SCC Version: SCC-7.0 (HM16.8)
Keywords: Cc: marie-pierre.gallasso@…, rajanj@…, jct-vc@…


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 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 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.

Attachments (1)

MergeCandidateRound.patch (11.4 KB) - added by libin 4 years ago.

Download all attachments as: .zip

Change History (3)

Changed 4 years ago by libin

comment:1 Changed 4 years ago by libin

The patch attached could solve the problem.

comment:2 Changed 4 years ago by libin

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r4901.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • Bin Li(Reporter, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • marie-pierre.gallasso@…(Subscriber)
  • rajanj@…(Subscriber)