Typo in 8.5.5.7 Derivation process for luma affine control point motion vector predictors

[chhuanb]

During the discussion of ticket 1182, another issue in 8.5.5.7 was found.

In "8.5.5.8 Derivation process for constructed affine control point motion vector prediction candidates", The third (bottom-left) control point motion vector cpMvLX[ 2 ] is derived regardless the numCpMv. The output described in 8.5.5.8 is: "the constructed affine control point motion vector prediction candidiates cpMvLX[ cpIdx ] with cpIdx = 0..2 and X being 0 or 1."

But in step 6 of 8.5.5.7, it's described as "and cpMvpLX[ cpIdx ] with cpIdx = 0..numCpMv − 1 as outputs".

In step 7, cpMvpLX[2] is reused regardless numCpMv:

7. The following applies for cpIdx = 2..0:

– When numCpMvpCandLX is less than 2 and availableFlagLX[ cpIdx ] is equal to 1, the following assignments are made:
cpMvpListLX[ numCpMvpCandLX ][ 0 ] = cpMvpLX[ cpIdx ] (846)
cpMvpListLX[ numCpMvpCandLX ][ 1 ] = cpMvpLX[ cpIdx ] (847)
cpMvpListLX[ numCpMvpCandLX ][ 2 ] = cpMvpLX[ cpIdx ] (848)

So the output range in step 6 should be fixed to avoid using an undefined value in step 7.

Suggest fix:

6. When numCpMvpCandLX is less than 2, the following applies

– The derivation process for constructed affine control point motion vector prediction candidate as specified in clause 8.5.5.8 is invoked with the luma coding block location ( xCb, yCb ), the luma coding block width cbWidth, the luma coding block height cbHeight, and the reference index of the current coding unit refIdxLX as inputs, and the availability flag availableConsFlagLX, the availability flags availableFlagLX[ cpIdx ] and cpMvpLX[ cpIdx ] with cpIdx = 0..2 as outputs.

[jlchen]

Thanks for reporting the issue. I think this is a bug and should be fixed. The cpMvpLX[ 2 ] will be used in step 7, therefore it should be assigned as the output of 8.5.5.8 regardless the value of numCpMv.

This will be fixed in JVET-S2001-vD release.