Opened 11 years ago

Closed 11 years ago

# 8.5.3.1.1 : singleMCLFlag = 1 leads to the same vector for every PB of the CB

Reported by: Owned by: Jing-Jing Chung bbross minor D10 Text D10 (L1003) v2 singleMCLFlag bbross, wjhan, jct-vc@…

### Description

In the 8.5.3.1.1 chapter, singleMCLFlag is used :

"When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS.
NOTE – When singleMCLFlag is equal to 1, all the prediction units of the current coding unit share a single merge candidate list, which is identical to the merge candidate list of the 2Nx2N prediction unit."

At the end of the chapter we have:

"The following assignments are made with N being the candidate at position merge_idx[ xP][ yP ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP][ yP ] ] ) and X being replaced by 0 or 1:
mvLX[ 0 ] = mvLXN[ 0 ] (8 79)
mvLX[ 1 ] = mvLXN[ 1 ] (8 80)
refIdxLX = refIdxLXN (8 81)
predFlagLX = predFlagLXN (8 82)"

============
So when singleMCLFlag = 1, since xP=xC and yP=yC for every PB of the CB, in this case every PB of the CB has the same result : mvLX, refIdxLX, predFlagLX.

My understanding is that, according to the note, the aim of singleMCLFlag=1, is that every PB of the CB has the same candidate list, and not necessarily the same vector. Moreover, there is a value of merge_idx[][] for every PB of the CB in the bitstream and here we only use the first one of the CB.

My proposal is that the initial values of xP and yP are kept and used in merge_idx. The text would be modified this way :

Let's set xP_init to xP, and yP_init to yP.
"When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS."
...
"The following assignments are made with N being the candidate at position merge_idx[ xP_init][ yP_init ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP_init][ yP_init ] ] ) and X being replaced by 0 or 1:"

### comment:1 Changed 11 years ago by DefaultCC Plugin

• Cc bbross wjhan jct-vc@… added

### comment:2 Changed 11 years ago by suzukiyos

Additionally, nPbW and nPbH need to be kept. And I think that the variable partIdx should be set equal to 0 when both nPbW and nPbH are nCS.
If my understanding is correct, the variable singleMCLFlag does not need to be referred in 8.5.3.1.2 when partIdx=0.

Attached please find my modifications to 8.5.3.1.1 and 8.5.3.1.2 as one of candidate modifications to fix this ticket.

### Changed 11 years ago by suzukiyos

Modifications on nPbW, nPbH, singleMCLFlag

### comment:3 in reply to: ↑ description Changed 11 years ago by shigeruf

This mismatch was introduced from JCTVC-J1003_d4 by the adoption of JCTVC-J0086.
However, original draft text of JCTVC-J0086 does not have this mismatch.
I think this mismatch can be easily fixed by reverting to the original text of JCTVC-J0086 as the HM software does so.

The draft text fixing this mismatch is attached as "JCTVC-K1003_v10_reverting_to_J0086.zip".

In the 8.5.3.1.1 chapter, singleMCLFlag is used :

"When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS.
NOTE – When singleMCLFlag is equal to 1, all the prediction units of the current coding unit share a single merge candidate list, which is identical to the merge candidate list of the 2Nx2N prediction unit."

At the end of the chapter we have:

"The following assignments are made with N being the candidate at position merge_idx[ xP][ yP ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP][ yP ] ] ) and X being replaced by 0 or 1:
mvLX[ 0 ] = mvLXN[ 0 ] (8 79)
mvLX[ 1 ] = mvLXN[ 1 ] (8 80)
refIdxLX = refIdxLXN (8 81)
predFlagLX = predFlagLXN (8 82)"

============
So when singleMCLFlag = 1, since xP=xC and yP=yC for every PB of the CB, in this case every PB of the CB has the same result : mvLX, refIdxLX, predFlagLX.

My understanding is that, according to the note, the aim of singleMCLFlag=1, is that every PB of the CB has the same candidate list, and not necessarily the same vector. Moreover, there is a value of merge_idx[][] for every PB of the CB in the bitstream and here we only use the first one of the CB.

My proposal is that the initial values of xP and yP are kept and used in merge_idx. The text would be modified this way :

Let's set xP_init to xP, and yP_init to yP.
"When singleMCLFlag is equal to 1, xP is set equal to xC, yP is set equal to yC, and both nPbW and nPbH are set equal to nCS."
...
"The following assignments are made with N being the candidate at position merge_idx[ xP_init][ yP_init ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP_init][ yP_init ] ] ) and X being replaced by 0 or 1:"

### comment:4 Changed 11 years ago by huiyong

• Version changed from D9 (K1003) v9 to D9 (K1003) v10

<Summarization of the issues>
For the last two steps in “8.5.3.1.1 Derivation process for luma motion vectors for merge mode”, which are shown below for convenience, xP, yP, nPbW, and nPbH shall be restored to the original values if singleMCLFlag is equal to 1. The software do this but the text does not. So this is a bug in the text.

``` 8. The following assignments are made with N being the candidate at position merge_idx[ xP][ yP ] in the merging candidate list mergeCandList ( N = mergeCandList[ merge_idx[ xP][ yP ] ] ) and X being replaced by 0 or 1:
mvLX[ 0 ] = mvLXN[ 0 ]	(8 79)
mvLX[ 1 ] = mvLXN[ 1 ]	(8 80)
refIdxLX = refIdxLXN	(8 81)
predFlagLX = predFlagLXN	(8 82)
9. When predFlagL0 is equal to 1 and predFlagL1 is equal to 1, and ( nPbW + nPbH ) is equal to 12, the following applies.
refIdxL1 = −1	(8 83)
predFlagL1 = 0	(8 84)
```

<Suggested fix>
I attached a fix for this text bug, which I believe reflects both Jing-Jing Chung’s point and Suzuki-san’s point. (I don’t think reverting to J0086 is still necessary in this case.)

### Changed 11 years ago by huiyong

A fix to this ticket.

### comment:5 Changed 11 years ago by bbross

• Version changed from D9 (K1003) v10 to D9 (K1003) v11

### comment:6 Changed 11 years ago by bbross

• Milestone D9 deleted
• Version changed from D9 (K1003) v11 to D10 (L1003) v1

### comment:7 Changed 11 years ago by bbross

• Milestone set to D10

### comment:8 Changed 11 years ago by bbross

• Version changed from D10 (L1003) v1 to D10 (L1003) v2

### comment:9 Changed 11 years ago by bbross

• 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(Owner, Subscriber, Participant)
• Hui Yong Kim(Participant)
• jct-vc@…(Subscriber)
• karl.sharman@…(Always)
• Karsten Suehring(Always)
• Woo-Jin Han(Subscriber)
• Yoshinori Suzuki(Participant)