Firefox 90 shows error message instead of showing AVIF created with `cavif`

nikonthethird commented 3 years ago

After updating to Firefox 90, a lot of the images created with cavif do not work anymore. Chrome still shows them. The archive Test.zip contains an image that worked in Firefox 89, but no longer in Firefox 90.

Is this because stricter validation? Is there a way to update the image without having to re-encode them? Or should I open an issue in the Mozilla bugtracker for this?

nikonthethird commented 3 years ago

I have opened an issue over at Bugzilla too because I think this might not be a Cavif problem at all.

I have images that still work, others that don't, it's weird. And to my knowledge, Firefox uses dav1d for AVIF decoding, so I passed a non-working image through davif and it came out fine on the other side.

nikonthethird commented 3 years ago

Good news, I "fixed" it by setting image.avif.compliance_strictness from 1 to 0 in about:config. I will leave this issue open because I still want to hear kornelski's opinion too.

This setting is new in Firefox 90, I will try to find out what it does and what has to change to avoid this in the future.

kornelski commented 3 years ago

AVIF suffers from being built on a tower of legacy video-oriented specs extended by committee to support everything for everyone.

It's a spec that refers to an older spec that builds on older spec that builds on another spec, on another spec, that is a fork of QuickTime for old MacOS. Most important spec in this pile is non-free behind ISO paywall. It's a lot of weird and useless stuff. It has like 5 places where it says it's an image, and just one image, and the image is supposed to be visible on screen, and it's not a video, etc. Just saying it has an alpha channel (1 bit of info) takes over 200 bytes.

I don't want to add to this pile of bloat just because someone has read more of these specs, and wrote more bloated code that literally doesn't do anything useful, and only requires everyone to send more bloat over the internet until the end of time, and have more code paths in decoders that refuse to display images that were demonstrated to work just fine without it.

nikonthethird commented 3 years ago

Just saying it has an alpha channel (1 bit of info) takes over 200 bytes.

That is insane and is totally the opposite of what I am using AVIF for (really small file sizes). I can see why you don't want to invest any effort into this madness.

I will still try to find out why some AVIF files work and some don't (same cavif version, btw). Maybe, just maybe it's not a trip down some neverending rabbit hole.

If it's OK with you, I will keep this issue open for a few more days while I take a look. I will close it when I find something (or nothing)...

nikonthethird commented 3 years ago

Just for reference if anyone comes across this, the setting image.avif.compliance_strictness is described as follows:

How strict we are in accepting/rejecting AVIF inputs according to whether they conform to the specification 0 = Permissive: accept whatever we can simply, unambiguously interpret 1 = Normal: reject violations of "shall" specification directives 2 = Strict: reject violations of "should" specification directives

If you get messages that AVIF images no longer work, change this setting to 0 in about:config.

nikonthethird commented 3 years ago

I have a bit more information.

Firefox calls the function mp4parse_avif_new and passes in the strictness setting.
It turns out mp4parse is a Rust project, so that's good news for me, it means I can just reference it as a crate and call the function read_avif with the not-working AVIF file and the strictness setting.
The offending thing! After setting up a small test application, I called read_avif above, and the location of the error is right here.

if !read_handler_box && b.head.name != BoxType::HandlerBox {
    fail_if(
        strictness != ParseStrictness::Permissive,
        "The HandlerBox shall be the first contained box within the MetaBox \
         per MIAF (ISO 23000-22:2019) § 7.2.1.5",
    )?;
}

The expected box type would have been HandlerBox ("hdlr"), but instead in my file it is PrimaryItemBox ("pitm").

That's all I could find so far. Is this something worth investigating further?

nikonthethird commented 3 years ago

I also found the change that introduced this check into Firefox. I see what you mean now. The HEIF spec really is unbelievably messy.

nikonthethird commented 3 years ago

It seems this particular problem at least is already fixed in avif-serialize, so as long as cavif is a fairly recent version, all AVIF files produced by it should work. I realized I was still using cavif 0.6.6 in one of my processes, so that explains where the images without the HandlerBox came from.

Sorry for the fuss. Now I have to figure out if it is possible to add this metadata thing without re-encoding 200000 images...

kornelski commented 3 years ago

Now I have to figure out if it is possible to add this metadata thing without re-encoding 200000 images

avif-parse + avif-serialize pair should do it. I think the only pain there is needing to read width/height from AV1 payload for the extra HEIF metadata that libavif/Chrome demands. I was going to write AV1 OBU parser, but haven't gotten around to it yet.

kornelski / cavif-rs

Firefox 90 shows error message instead of showing AVIF created with `cavif` #33