Multiple warnings on chroma_sample_position from av1C

[podborski]

We noticed multiple warnings for chroma_sample_position on the same file which should just appear once.

https://github.com/AOMediaCodec/av1-hdr10plus/blob/main/conformance/conformance_files/Netflix/sparks_libaom_4096x2160_0_888_hdr10plus.json

{
    "rule": "8",
    "id": "assert-5b56cde2",
    "details": "Section 2.2.1\nchroma_sample_position should be set to 2",
    "description": "chroma_sample_position should be set as 2, found 0"
},

Coverage report: https://aomediacodec.github.io/av1-hdr10plus/coverage/

[rbouqueau]

That's because the error is found multiple time from the data. In case of repetition of an error, what would you expect instead?

[podborski]

Ah, that is fine. I thought it was coming from the av1C and therefore expected it to appear just once. But this is the SH OBU thing obviously and it appears multiple times in samples. So this is fine.

I have one question though.
I checked the file and I see SH OBU is appearing 5 times in samples and this is what cw.exe is printing out. But I also see that the same SH OBU also appears one time in av1C. When following the rules from AV1 ISOBMFF spec on how to form the bitstream, the decoder will be getting the av1C.configOBUs on every key frame (we have 5) in front of all OBUs from the sample. That will lead to 10 SH OBUs in this example. So I guess in this case we should even expect 10 entries to appear in the validation json? @cconcolato any opinions? If this is the case, can the description also provide the location where for example the chroma_sample_position is coming from? (e.g.: chroma_sample_position from av1C.configOBUs or SH OBU from a sample).

[cconcolato]

We probably should update the AV1-ISOBMFF spec to indicate that duplicate (SH) OBUs are removed when forming the bitstream.

[rbouqueau]

Any news here?