id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
1189	Typo in 8.5.5.7 Derivation process for luma affine control point motion vector predictors	chhuanb		"During the discussion of [https://jvet.hhi.fraunhofer.de/trac/vvc/ticket/1182 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.

"	defect	closed	minor		spec		fixed		ksuehring bbross XiangLi fbossen jvet@…