-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Firefox 90 shows error message instead of showing AVIF created with cavif
#33
Comments
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. |
Good news, I "fixed" it by setting 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. |
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. |
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 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)... |
Just for reference if anyone comes across this, the setting
If you get messages that AVIF images no longer work, change this setting to 0 in |
I have a bit more information.
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",
)?;
}
That's all I could find so far. Is this something worth investigating further? |
I also found the change that introduced this check into Firefox. I see what you mean now. The HEIF spec really is unbelievably messy. |
It seems this particular problem at least is already fixed in Sorry for the fuss. 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. |
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?
The text was updated successfully, but these errors were encountered: