Opened 9 years ago

Closed 9 years ago

#727 closed defect (fixed)

mismatch between the WD text and the HM software on derivation of spatial merging candidates

Reported by: asimpson Owned by:
Priority: minor Milestone: HM-9.0
Component: HM Version: HM-8.0
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

In 8.5.2.1.2 the text specifies a number of conditions for inclusion of a candidate in the merge list such as:

– (xP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (xN >> (log2_parallel_merge_level_minus2 + 2)) and (yP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (yN >> (log2_parallel_merge_level_minus2 + 2)).

– singleMCLFlag is equal to 0 and PartMode of the current prediction unit is PART_2NxN or PART_2NxnU or PART_2NxnD and partIdx is equal to 1 and N is equal to B1

– singleMCLFlag is equal to 0 and PartMode of the current prediction unit is PART_Nx2N or PART_nLx2N or PART_nRx2N and partIdx is equal to 1 and N is equal to A1

– N is equal to B2 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have the same motion vectors and the same reference indices

In the software if the "parallel merge" test results in a particular candidate N not being added to the list then that N is not tested for equivalence when a subsequent candidate is considered.

However if a particular candidate N is not added as the current PU is the second partition of a 2 partition CU then that N is still used for the equivalence test when a subsequent candidate is considered.
See TComDataCU::getInterMergeCandidates()

Intuitively it would seem that a candidate should not be excluded from the list just because it has the same MV and RefIdx as another candidate that was not added to the list.

Change History (8)

comment:1 Changed 9 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

comment:2 Changed 9 years ago by asimpson

As far as I see this mismatch between the HM and the WD still exists in version 8.1 of the HM.

For example in getInterMergeCandidates() if pcCULeft fails parallel merge test then it is set to NULL.

    if (!pcCULeft->isDiffMER(xP -1, yP+nPSH-1, xP, yP))
    {
      pcCULeft = NULL;
    }

This means that pcCUAbove can still be added even if it has the same motion as pcCULeft.

  if ( pcCUAbove && !pcCUAbove->isIntra( uiAbovePartIdx ) 
    && !(uiPUIdx == 1 && (cCurPS == SIZE_2NxN || cCurPS == SIZE_2NxnU || cCurPS == SIZE_2NxnD))
    && ( !pcCULeft || pcCULeft->isIntra( uiLeftPartIdx ) || !pcCULeft->hasEqualMotion( uiLeftPartIdx, pcCUAbove, uiAbovePartIdx ) ) )
{
... Add above predictor
}

However in the WD it states that B1 will not be added if.

–	N is equal to B1 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have 
        the same motion vectors and the same reference indices

This does not test if A1 was available, just if it has the same MV & Ref, and hence is different from the HM.

Perhaps the clause should read something like:

–	N is equal to B1 and the prediction units covering luma location ( xA1, yA1 ) and luma location ( xN, yN ) have 
        the same motion vectors and the same reference indices and predFlagLXA1 is equal to 1

If so then there would still be a mismatch as pcCULeft is not set to NULL if it fails the following test.

    !(uiPUIdx == 1 && (cCurPS == SIZE_2NxN || cCurPS == SIZE_2NxnU || cCurPS == SIZE_2NxnD))

comment:3 Changed 9 years ago by sier

Another mismatch between the WD text and the HM software on derivation of spatial merging candidates is that:
In HM8, when N is Intra coded block, there is no MVP candidate related to N.
However in WD, availableFlagN is set equal to 1 even if N is Intra coded block. (availableFlagN=1 means the MVP candidate related to N will be added to list)

it seems to solve the issue by following changes (the last sentence is added):
– If one or more of the following conditions are true with X being replaced by 0 and 1, the availableFlagN is set equal to 0, both components mvLXN are set equal to 0, refIdxLXN is set equal to −1 and predFlagLXN is set equal to 0.
– (xP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (xN >> (log2_parallel_merge_level_minus2 + 2)) and (yP >> (log2_parallel_merge_level_minus2 + 2)) is equal to (yN >> (log2_parallel_merge_level_minus2 + 2)).
– N is equal to B2 and availableFlagA0 + availableFlagA1 + availableFlagB0 + availableFlagB1 is equal to 4.
– availableN is equal to FALSE
– PredMode[xN][yN] is equal to MODE_INTRA
...

comment:4 Changed 9 years ago by bbross

The second mismatch does not exists since the condition on INTRA is already checked in "6.4.2 Derivation process for prediction block availability" used to derive availableN.

comment:5 Changed 9 years ago by sier

You are right, the second mismatch does not exist.
At the meantime, I also believe that the first mismatch has been fixed in HM9 where a Macro "MERGE_CLEANUP_AND_K0197" is introduced.

comment:6 Changed 9 years ago by ksuehring

So, can this be closed as "fixed in HM 9.0"?

comment:7 Changed 9 years ago by asimpson

Yes I agree that it appears to be fixed.

comment:8 Changed 9 years ago by ksuehring

  • Milestone set to HM-9.0
  • Resolution set to fixed
  • Status changed from new to closed
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

  • Benjamin Bross(Participant)
  • David Flynn(Subscriber)
  • Frank Bossen(Subscriber)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Participant, Always)
  • sier(Participant)