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.

Modifications on nPbW, nPbH, singleMCLFlag

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

Replying to Jing-Jing Chung:

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:"

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

A fix to this ticket.