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.

In Annex C, it seems that some syntax elements and variables are checked without being always defined.

In C.1 General step 9: "When the PT SEI message associated with AU 0 has pt_cpb_alt_timing_info_present_flag equal to 1, …". But pt_cpb_alt_timing_info_present_flag is not always signalled. So adding an inference for this syntax element may be necessary.

In C.2.2 and C.2.3, the variable DefaultInitCpbParamsFlag is checked without necessarily being defined, since it is defined in C.1 only when pt_cpb_alt_timing_info_present_flag is equal to 1. Either the value of pt_cpb_alt_timing_info_present_flag should be added as condition before checking the value of DefaultInitCpbParamsFlag or there should be a default value of DefaultInitCpbParamsFlag specified when pt_cpb_alt_timing_info_present_flag is equal to 0.

Is the second condition in the definition of the numbers n2 and n3 correct: "The associated BP SEI message has bp_alt_cpb_params_present_flag equal to 1"? Why is bp_alt_cpb_params_present_flag rather than pt_cpb_alt_timing_info_present_flag considered given that pt_cpb_alt_timing_info_present_flag seems to be the syntax element used everywhere else when using alternate timings?

In C.2.3, the PT SEI syntax elements cpb_alt_initial_removal_delay_delta, cpb_alt_initial_removal_offset_delta, cpb_delay_offset and dpb_delay_offset are mentioned. These syntax elements do not exist. The prefix "pt_nal" or "pt_vcl" is missing.

A patch has been provided by Tomohiro Ikai:

I'd like to share a patch to fix the trace functionality. #define FIX_TRACE 1

With this, TraceEnc.txt basically matches with TraceDec.txt, which is very useful for debugging. After KTA1, some trace-related fix seems have been done with the macro "DEBUG". The changes are straight forward, so we may remove the macro while integration.

Note: Since the amount of the trace text in ecodeBin()/encodeBin() is too much, I suggest to disable them (included in my patch)

I'm filing it here for later application to the HM-16.6 based branch.