id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
567	Issues with numSbX and numSbY in Section 8.5.5.2	bheng		"'''1.) SBTMVP values overwritten by Affine'''
For SBTMVP, the numSbX and numSbY values get set in Step 1, but they get overwritten in Step 2 (the affine candidate derivation), regardless of whether the final selected vector was Sub-PU or Affine.

It seems like there should be something like a numSbColX / numSbColY and a separate numSbAffineX / numSbAffineY, and the final values should be determined based on whether the selected candidate was SbCol or not.

'''2.) Unassigned Sub-Block Size'''
If SBTMVP is enabled, but not available, numSbX and numSbY don’t get set to anything in Section 8.5.5.3. And, if affine is also disabled (sps_affine_enabled_flag = 0), numSbX and numSbY don’t get set to anything in Section 8.5.5.2 either.  Therefore, the resulting (0,0) candidate, derived in Step 8, doesn’t have a numSbX or numSbY assigned.

Normally the sub-block size of a (0,0) candidate wouldn’t make much difference (4x4 vs 8x8), but RPR results are different depending on whether they are applied on an 8x8 or 4x4 basis, so some valid value has to be assigned here.

Note, currently VTM treats this (0,0) candidate in this situation like affine (4x4 sub-blocks) even though affine is disabled.  This may not be the desired behavior.
"	defect	closed	minor		spec	VVC D7 vE	fixed		ksuehring bbross XiangLi fbossen jvet@…