Bug of parsing max num of GPM candidates

[chunchic]

In JVET-Q2001-vC (as shown below), the syntax max_num_merge_cand_minus_max_num_gpm_cand is parsed when MaxNumMergeCand is at least 3.

		if( sps_gpm_enabled_flag  &&  MaxNumMergeCand  >=  3 )	
			max_num_merge_cand_minus_max_num_gpm_cand	ue(v)

However, the VTM-8.0rc1 implemented this threshold value by using 2, but not the specified 3, causing inconsistency between SW and Spec.
As the spec specifies, max_num_merge_cand_minus_max_num_gpm_cand needs to be parsed only when MaxNumMergeCand is at least 3.

This SW bug can be found in VTM-8.0rc1 at both VLCWriter.cpp and VLCReader.cpp, as follows.

[VLCWriter.cpp]
Line 2244: if (sps->getUseGeo() && picHeader->getMaxNumMergeCand() >= '''2''') 

[VLCReader.cpp]
Line 3178 : if (sps->getUseGeo() && picHeader->getMaxNumMergeCand() >= '''2''')

The below is the correction.

[VLCWriter.cpp]
Line 2244: if (sps->getUseGeo() && picHeader->getMaxNumMergeCand() >= '''3''') 

[VLCReader.cpp]
Line 3178 : if (sps->getUseGeo() && picHeader->getMaxNumMergeCand() >= '''3''')

[XiangLi]

Thanks for the report. This looks related to HLS adoption JVET-Q0798, which has not been integrated into software yet. JVET-Q0798 is scheduled in VTM-8.1.

[XiangLi]

Integrated in ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1427.