In the function MergeItem::importMergeInfo, the variable mergeIdx becomes larger than MRG_MAX_NUM_CANDS and overflows the array mergeCtx.mvFieldNeighbours. This seems to occur when the function importMergeInfo is called from EncCu::addMmvdCandsToPruningList, so the value of mmvdIdx.val in the argument of mmvdMerge->importMergeInfo appears to be incorrect.

For 12b444vvc1_A_Sony_2.bit, the second decode frame(poc 32), and cu position (64,68) The treeType is equal to SINGLE_TREE, sps_chroma_format_idc is equal to 3, intra_chroma_pred_mode is equal to 0,and IntraMipFlag[ xCb ][ yCb ] is equal to 1

based on

1. If IntraMipFlag[ xCb + cbWidth / 2 ][ yCb + cbHeight / 2 ] is equal to 1, lumaIntraPredMode is set equal toINTRA_PLANAR.
2. Table 20

we need set IntraPredModeC to 66, which conflicts with vtm code ​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/blob/master/source/Lib/CommonLib/UnitTools.cpp#L734

could you explain why?

thank you.

Test bitstreams in the FDIS and FDIS_r1 directory are supposed to be the same, except for removal of company names.

It was found though, that in the transition of STILL_B_ERICSSON_1 to STILL_B_1 both YUV MD5 hash and OPL file changed.

The bitstream files are identical and contain five frames. The OPL file of the STILL_B_ERICSSON_1 stream contains all the frames in the stream. The OPL file for STILL_B_1 contains only the first frame. The change for the YUV file looks similar.

The stream is specified as follows:

Test bitstream STILL_B_ERICSSON

Specification: This bitstream tests a Main 10 Still Picture decoder’s capability of decoding the first picture of a bitstream conforming to the Main 10 profile when the first picture of the bitstream is a GDR picture with ph_recovery_poc_cnt equal to 0.

Functional stage: Still picture

Purpose: Check that a Main 10 Still Picture decoder can decode the first picture of a Main 10 bitstream when the first picture of the bitstream is a GDR picture with ph_recovery_poc_cnt equal to 0.

The bitstream is a Main 10 bistream, not a still picture profile as the name may suggest. A multi-profile decoder like VTM cannot determine from the bitstream that it would be expected to only decode the first picture. A Main 10 Still Picture profile bitstream would only be allowed to contain a single picture.

If a Main 10 capable decoder sees a bitstream that is marked as Main 10, it should obviously decode all pictures in the stream. The single frame decoding case seems like a special case for a Main 10 stream being tested with a still picture only decoder. Expecting that behavior as the default seems confusing.

Thus I think the change of OPL and MD5 may be not intentional. For an intentional change, I would also expect the version of the stream to be incremented.

A similar issue seems to exist in STILL444_B_ERICSSON_1 and STILL444_B_1.