STILL_B_1 / STILL_B_ERICSSON_1 checksum and OPL difference

[ksuehring]

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.

[adamjw]

A similar issue seems to exist in STILL444_B_ERICSSON_1 and STILL444_B_1.

[martin.m.pettersson]

Thanks for noticing, Karsten.

I agree, the contents of the zip-files are not supposed to change from the FDIS versions of the conformance streams. The FDIS versions of the STILL_B_ERICSSON_1 and STILL444_B_ERICSSON_1 conformance streams contain .opl and .md5 files for both the full video decode and the decoded first picture. The new FDIS_r versions only contains .opl and .md5 files for the first decoded picture.

Please redo the renaming of the STILL_B_ERICSSON_1 and STILL444_B_ERICSSON_1 conformance streams without changing the content of the files or removing any files.

And yes, the STILL_B_ERICSSON_1 and STILL444_B_ERICSSON_1 conformance streams are Main 10 and Main 10 4:4:4 bitstreams that are used to check the decoder capabilities for Main 10 Still Picture and Main 10 4:4:4 Still Picture decoders, see text below. These conformance streams should of course also be fully decodable by a Main 10 / Main 10 4:4:4 decoder, hence the duplicate .opl and .md5 files.

A.3 Profiles

...
Decoders conforming to the Main 10 Still Picture profile at a specific level of a specific tier shall also be capable of decoding of the first picture of a bitstream when both of the following conditions apply:

• That bitstream is indicated to conform to the Main 10 profile, to conform to a tier that is lower than or equal to the specified tier, and to conform to a level that is not level 15.5 and is lower than or equal to the specified level.
• That picture is an IRAP picture or is a GDR picture with ph_recovery_poc_cnt equal to 0, is in an output layer, and has ph_pic_output_flag equal to 1.

...
Decoders conforming to the Main 10 4:4:4 Still Picture profile at a specific level of a specific tier shall also be capable of decoding of the first picture of a bitstream when both of the following conditions apply:

• That bitstream is indicated to conform to the Main 10 or Main 10 4:4:4 profile, to conform to a tier that is lower than or equal to the specified tier, to conform to a level that is not level 15.5 and is lower than or equal to the specified level.
• That picture is an IRAP picture or is a GDR picture with ph_recovery_poc_cnt equal to 0, is in an output layer, and has ph_pic_output_flag equal to 1.

[iole_moccagatta]

STILL_B_1.zip

[iole_moccagatta]

STILL444_B_1.zip

[iole_moccagatta]

Karsten,

good catch. Indeed packets in FDIS and FDIS_r1 are supposed to be the same, except for i) removal of company names, and ii) removal of email addresses.

I re-generated STILL_B_1.zip and STILL444_B_1.zip - see attached. Please take a look and let me know if they are OK.

[martin.m.pettersson]

Fixing STILL_B_1.yuv.md5

[martin.m.pettersson]

Fixing STILL444_B_1.yuv.md5

[martin.m.pettersson]

Thanks Iole,

It all looks good to me except that the STILL_B_1.yuv.md5 and STILL444_B_1.yuv.md5 still have different md5 checksums than STILL_B_ERICSSON_1.yuv.md5 and STILL444_B_ERICSSON_1.yuv.md5. I have attached zip-files where that has been fixed.

[iole_moccagatta]

Martin,

thanks. Will upload them to dropbox.

[iole_moccagatta]

The 2 packages are correctly decoded by VTM-20.2 and have been uploaded to /jvet-site/bitstream_exchange/VVC/under_test/VTM-20.2_r1.

I think we can close this ticket.