search

AOMediaCodec / libavif

libavif - Library for encoding and decoding .avif files
Other
1.44k stars 187 forks source link

MIAF requires the mif1 brand, but libavif doesn't #480

Open joedrago opened 3 years ago

joedrago commented 3 years ago

@wantehchang @kornelski @cconcolato @baumanj

Stemming from this GitHub issue: https://github.com/mozilla/mp4parse-rust/issues/236

libavif currently only pays attention to the avif and avis brands on read, but emits all of the proper/relevant brands on write. However, AVIF files are MIAFs, and the MIAF standard says:

The FileTypeBox shall contain, in the compatible_brands list, the following (in any order):

  • 'mif1' (specified in ISO/IEC 23008-12).
  • brand(s) identifying conformance to this document (specified in Clause 10).

The FileTypeBox should also contain brands that identify the MIAF profile(s), to which the file conforms (specified in Annex A or externally), and possibly other brands to which the file conforms.

Files shall also carry a compatible brand to identify the MIAF profile to which the file conforms, as defined in Annex A or external specifications.  

The "shall" there is pretty clear that this is a restriction, and that an AVIF without mif1 is in error, however, the second bullet there suggests that if we read it this way, any file that is legally one of the brands in Clause 10 but doesn't report that brand is also in error. For example, if an AVIF image sequence happens to conform to the requirements of a burst capture, it similarly "shall" have MiBu in it.

This seems a bit overreaching to me, honestly. From my perspective, brands help decoders that can only do a subset of decoding "everything BMFF can deliver" (read: all decoders) figure out if they can handle the file. Failing to inject mif1 into an AVIF should make it so that a decoder that only can decode mif1 files can't decode it is unfortunate, but shouldn't block an otherwise valid AVIF, in my opinion.

@cconcolato - Is there any way we can amend the MIAF standard to change 7.2.1.2 "shall" into a "should"? The wording here is pernicious, in my opinion. I'd way rather not be required to bail out on missing compatible brands. It feels backwards to me.

baumanj commented 3 years ago

I would likewise be happy to see that requirement relaxed in MIAF. It's pretty confusing, but I also think it's important for implementations to adhere to the standard strictly to achieve good compatibility and adoption, especially at this early stage.

How likely is getting such a change through, and what would the timeline look like?

cconcolato commented 3 years ago

however, the second bullet there suggests that if we read it this way, any file that is legally one of the brands in Clause 10 but doesn't report that brand is also in error.

MIAF Amd2 fixes that part as follows:

The FileTypeBox shall contain, in the compatible_brands list, the 'mif1' brand (specified in ISO/IEC 23008-12).

The FileTypeBox should also contain brands that identify the MIAF profile(s), to which the file conforms (specified in Annex A or externally), and possibly other brands to which the file conforms.

The use of 'externally' is meant to cover AVIF. IIRC, the requirement on 'mif1' was added to enable tools that do codec-agnostic processing of MIAF files can work on any MIAF file (irrespective of the codec). Relaxing the rule to make it a 'should' can always be envisaged but it will take discussions and time ...

joedrago commented 3 years ago

Alright, so is your recommendation that we add the brand requirement to libavif's parse?

wantehchang commented 3 years ago

ISO/IEC 23008-12:2017(E) also says, in 10.2.1.1 Requirements on files:

Files shall contain the brand 'mif1' in the compatible brands array of the FileTypeBox.

So there are two standards that use the word "shall" in the requirements on having mif1 in compatible brands.