Analyze specification to determine how many conformance bitstreams are needed

[cconcolato]

[cconcolato]

Per Paul's analysis (to be uploaded soon), I propose to create the following files, in two sets: valid files and invalid files.

Valid files exercise "shall" and "should" statements. In particular, for "should" statements, the idea is to show the possible variations allowed by the spec, even if not necessarily recommended. If we believe some variations should not be allowed, we should change the spec.

Invalid files would be used in conjunction with a validation tool such as https://github.com/gpac/ComplianceWarden that would emit errors when processing those files. This should help implementers not produce such invalid files. It should be possible to create invalid files by using hex editors for example. Obviously, creation of such files should not be encouraged and real player implementations should think of strategies to handle them.

• valid (V) files

  • V1 a file following all shalls and shoulds, with no HDR10 Static Metadata, no film grain, but with all frame configurations (show_frame=1, show_frame=0, show_existing_frame=1)
  • V2 a file with a different value for VideoFullRangeFlag
  • V3 a file with a different subsampling
  • V4 a monochrome file
  • V5 a file with a different chroma sample position
  • V6 a file with HDR10 static metadata present
  • V7 a file with film grain
  • V8 a file packaged in MP4, non encrypted, with cdm4 brand
  • V9 a file packaged in MPEG-2 TS
  • V10 a file packaged in MP4, and encrypted
  • V11 a file packaged in MP4, without the cdm4 brand
  • V12 a file with its DASH manifest without HDR descriptors
  • V13 a file with its DASH manifest with an HDR descriptor

• invalid (I) files:

  • I1 a file without HDR10+ Metadata OBU (invalid per 2.1a)
  • I2 a file with T.35 OBU with a wrong value for either country code (or terminal provider code, or terminal provider oriented code) per 2.1b. Potentially 3 files.
  • I3 a file with invalid color configuration (either color primaries, or transfer characteristics, or matrix coefficients) per 2.2.1b. Potentially 3 files.
  • I4 a file with a frame with show_frame=1 missing the HDR10+ OBU (2.2.2a)
  • I5 a file with a frame with show_frame=1 with 2 HDR10+ OBUs (2.2.2a)
  • I6 a file with a frame with show_frame=1 not at the right place (e.g. between tile groups, or before the sequence header)(2.2.2a)
  • I7 same as above for show_existing_frame=1 (2.2.2a)
  • I8 a file with a frame with show_frame=0 and an HDR10+ OBU (2.2.2b)
  • I9 a file packaged in MP4 with HDR10+ OBU in the config OBUs (3.1)
  • I10 a file packaged in MPEG-2TS with HDR10+ OBU in the config OBUs (3.1)
  • I11 a file with AV1 Metadata Sample Group (3.2a)
  • I12 a file packaged in MP4, and encrypted with encrypted HDR10+ OBUs (3.2b)
  • I13 a file packaged in MP4, and encrypted with encrypted HDR10 static metadata OBUs (3.2c)

[cconcolato]

We are also missing the following files:
[] multiple tile groups and invalid file with HDR10+ Metadata OBU in between the frame header OBU and the tile group OBU or between tile group OBUs

[cconcolato]

Clarified in meeting that Samsung agrees with the above list.

[cconcolato]

We can now remove the banner

WARNING: These files are still under review.

[cconcolato]

We need to confirm the status of the conformance files. Do they form a part of the Final Deliverable (kind of like the reference software?)?