In VVCD5, the inverse angle parameter invAngle is derived based on intraPredAngle as follows: invAngle = Round((256*32)/"intraPredAngle" ) However, in VTM-5.0, the invAngle should be 161 when intraPredAngle equals to 51 rather than 160.

8.4.3 Derivation process for chroma intra prediction mode ... The corresponding luma intra prediction mode lumaIntraPredMode is derived as follows: – If intra_mip_flag[ xCb ][ yCb ] is equal to 1, lumaIntraPredMode is set equal to INTRA_PLANAR. – Otherwise, if CuPredMode[ 0 ][ xCb ][ yCb ] is equal to MODE_IBC or MODE_PLT, lumaIntraPredMode is set equal to INTRA_DC. – Otherwise, lumaIntraPredMode is set equal to IntraPredModeY[ xCb + cbWidth / 2 ][ yCb + cbHeight / 2 ].

It could seen that when checking the luma prediction mode equal to MIP/IBC/Palette, the CU covering the corresponding luma sample of the top-left position of current chroma block (named top CU) is used. However, in the SW, CU covering the corresponding luma sample of the center position of current chroma block (named center CU) is checked.

In addition, if the decoder follows the spec, IntraPredModeY[ xCb + cbWidth / 2 ][ yCb + cbHeight / 2 ] may be used without being defined. For example, the center CU may be coded with IBC/Palette mode while the top CU is intra coded.

A possible solution is to check center CU's mode, and the spec changes could be like: The corresponding luma intra prediction mode lumaIntraPredMode is derived as follows: – If intra_mip_flag[ xCb + cbWidth / 2 ][ yCb + cbHeight / 2] is equal to 1, lumaIntraPredMode is set equal to INTRA_PLANAR. – Otherwise, if CuPredMode[ 0 ][ xCb + cbWidth / 2][ yCb + cbHeight / 2] is equal to MODE_IBC or MODE_PLT, lumaIntraPredMode is set equal to INTRA_DC. – Otherwise, lumaIntraPredMode is set equal to IntraPredModeY[ xCb + cbWidth / 2 ][ yCb + cbHeight / 2 ].

Gcc compilation can fail in TEncSearch.cpp, in TEncSearch::estIntraPredQT (line 3144).

The indication is "array bounds exceeded". The compiler has partially followed the logic of

Int numModesAvailable = 67; ... if (doFastSearch) ... else ... problem here, with

for( Int i=0; i < numModesForFullRD; i++)

uiRdModeList[i] = i;

The compiler assumes that the array is being initialized up to numModesAvailable (deduced from previous tests), which is bigger than the array size.

From what I can see, doFastSearch is always true and the else case is never executed. If that is true, the else case can be deleted as in the supplied patch.

If the else-case is to be left in for future-proofing any up coming logic, the array size will have to be increased.