Enable AVIF support by default
Categories
(Core :: Graphics: ImageLib, task, P1)
Tracking
()
People
(Reporter: jbauman, Assigned: jbauman)
References
(Blocks 1 open bug)
Details
(Keywords: dev-doc-complete)
Attachments
(4 files)
What it says on the tin, basically. This amounts to setting image.avif.enabled
to true and letting it ride the trains to release.
Assignee | ||
Comment 1•3 years ago
|
||
Pushed by csabou@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/feef6926b977 Enable AVIF support by default. r=aosmond,preferences-reviewers
Comment 3•3 years ago
|
||
Backed out changeset feef6926b977 (bug 1682995) for test_accept_header.html failures.
Backout link: https://hg.mozilla.org/integration/autoland/rev/55143e2b92a52bf0a944a383932a4933a854e51d
Failure log: https://treeherder.mozilla.org/logviewer?job_id=324850432&repo=autoland&lineNumber=4150
[task 2020-12-17T19:53:15.275Z] 19:53:15 INFO - TEST-START | netwerk/test/mochitests/test_accept_header.html
[task 2020-12-17T19:53:15.452Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?iframe
[task 2020-12-17T19:53:15.529Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.550Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: iframe
[task 2020-12-17T19:53:15.552Z] 19:53:15 INFO - TEST-INFO | started process screentopng
[task 2020-12-17T19:53:15.568Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?image
[task 2020-12-17T19:53:15.596Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.624Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?style
[task 2020-12-17T19:53:15.640Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.680Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?worker
[task 2020-12-17T19:53:15.696Z] 19:53:15 INFO - test_accept_header /tests/netwerk/test/mochitests/test_accept_header.sjs?get
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - TEST-INFO | screentopng: exit 0
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_accept_header.html | Accept header: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 - got "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8", expected "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - SimpleTest.is@SimpleTest/SimpleTest.js:500:14
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - test_last_request_and_continue/<@netwerk/test/mochitests/test_accept_header.html:20:7
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: image
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - TEST-UNEXPECTED-FAIL | netwerk/test/mochitests/test_accept_header.html | Accept header: image/webp,*/* - got "image/avif,image/webp,*/*", expected "image/webp,*/*"
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - SimpleTest.is@SimpleTest/SimpleTest.js:500:14
[task 2020-12-17T19:53:15.813Z] 19:53:15 INFO - test_last_request_and_continue/<@netwerk/test/mochitests/test_accept_header.html:20:7
[task 2020-12-17T19:53:15.814Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: style
[task 2020-12-17T19:53:15.814Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Accept header: text/css,*/*;q=0.1
[task 2020-12-17T19:53:15.815Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Expected: worker
[task 2020-12-17T19:53:15.815Z] 19:53:15 INFO - TEST-PASS | netwerk/test/mochitests/test_accept_header.html | Accept header: */*
[task 2020-12-17T19:53:15.815Z] 19:53:15 INFO - GECKO(3092) | MEMORY STAT | vsize 2564MB | residentFast 155MB | heapAllocated 10MB
[task 2020-12-17T19:53:15.816Z] 19:53:15 INFO - TEST-OK | netwerk/test/mochitests/test_accept_header.html | took 462ms
Comment 4•3 years ago
|
||
The following also seems to start perma failing with the backed out changes: https://treeherder.mozilla.org/logviewer?job_id=324855672&repo=autoland&lineNumber=4508
Backout by csabou@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/26d8d2248fcd Backed out changeset feef6926b977 for test_accept_header.html failures CLOSED TREE
Assignee | ||
Comment 6•3 years ago
|
||
I'm currently looking at this. The fix to test_accept_header.html is straightforward, but it led me to run a full mochitest suite and that showed some less-obvious errors. In particular image/test/mochitest/test_bug496292.html is failing, but it took me awhile (I got sidetracked by bug 1682709) to track down why.
To hopefully avoid another backout, I've just replaced all the instances of "image/webp,*/*"
(our previous Accept header) in our test code with "image/avif,image/webp,*/*"
. I'll run another try and hopefully that one will be green.
Assignee | ||
Comment 7•3 years ago
|
||
Sadly there still seem to be some test failures that, while it's not immediately clear why they'd be affected by this, are locally reproducible only with this change. For example: devtools/client/netmonitor/test/browser_net_copy_headers.js.
So, I'm looking into those and won't try to re-land until I've got them sorted.
Comment 8•3 years ago
|
||
(In reply to Jon Bauman [:jbauman:] from comment #7)
Sadly there still seem to be some test failures that, while it's not immediately clear why they'd be affected by this, are locally reproducible only with this change. For example: devtools/client/netmonitor/test/browser_net_copy_headers.js.
That test will poll the clipboard until it finds an expected strings. When it can't find the expected string it will time out. https://searchfox.org/mozilla-central/source/devtools/client/netmonitor/test/browser_net_copy_headers.js#45
So, I'm looking into those and won't try to re-land until I've got them sorted.
Assignee | ||
Comment 9•3 years ago
|
||
Thanks Tom, I found that as well (unfortunately before I saw your comment). Not sure how I missed it the first time around, but I'm pretty sure I've addressed all the locations in test code where image/webp
appears and if this next try run looks good, I'll try to land this again.
Assignee | ||
Comment 10•3 years ago
|
||
I don't think any of the remaining failures are due to the changes for this issue. However, I don't want to land a change directly before being unavailable during the holiday time, so wait on this until I'm back.
Comment 11•3 years ago
|
||
Hi! Excited to see this, but maybe bug 1654461 should be fixed first? Both libavif and squoosh.app produce full range AVIF images by default, and it's better to use full range in image encoding to prevent banding artifact.
Comment 12•3 years ago
|
||
https://code.videolan.org/videolan/dav1d/-/blob/master/NEWS
https://code.videolan.org/videolan/dav1d/-/releases
Please update to dav1d 0.8.1 if possible for faster AVIF decoding.
Assignee | ||
Comment 13•3 years ago
|
||
Per bug 1680396, we'll update to the latest dav1d version later this month
Comment 14•3 years ago
|
||
Pushed by cbrindusan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4267ac191113 Enable AVIF support by default. r=aosmond,preferences-reviewers,necko-reviewers,valentin
Assignee | ||
Comment 16•3 years ago
|
||
Indeed! Thanks, Ryan
Comment 17•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 18•3 years ago
|
||
Jon, do you have a suggestion for the wording of the release note and maybe an url to an explainer we could link to from the release notes? Thanks
Assignee | ||
Comment 19•3 years ago
|
||
Hi Pascal, this is adapted from what I suggested back when AVIF was partially implemented, but disabled by default
[Why is this notable]: A new image format with excellent compression and no patent restrictions developed by the Alliance for Open Media
[Suggested wording]: Basic AVIF support is enabled in this release. Some advanced features like animated images and colorspace support is still in development. See https://bugzilla.mozilla.org/show_bug.cgi?id=1682995 and related issue for more detail. It can be disabled by setting image.avif.enabled to false in about:config.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#AVIF and https://en.wikipedia.org/wiki/AV1#AV1_Image_File_Format_(AVIF)
I'm not sure if we tend to include links to non-mozilla blog posts in these kinds of notes, but https://jakearchibald.com/2020/avif-has-landed/ is a very good write up on the format generally and includes several examples.
Comment 20•3 years ago
|
||
I went with this note:
Basic AVIF support is enabled in Firefox 86. Some advanced features like animated images and colorspace support are still in development (see bug 1682995 and dependencies)
I am linking to our own documentation and adding the dev-doc-needed
keyword to this bug as we will need to also add this information to https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/86 and also update https://developer.mozilla.org/docs/Web/Media/Formats/Image_types#AVIF to indicate that this is no longer behind an about:config flag.
The final release note will likely be rewritten by our marketing team for a more end-user focused wording.
Thanks!
Comment 21•3 years ago
|
||
FYI Documentation for the FF86 release of this feature is now done/being reviewed. This was mostly already done (we thought this would release in FF83). Essentially this confirms the MIME types, change to HTTP accepts, release note, removes experimental tagging etc.
Full details can be found here: https://github.com/mdn/content/issues/1726#issuecomment-769577479
Updated•3 years ago
|
Comment 22•3 years ago
|
||
I've commented over on 1443863 that it will be problematic for AVIF to be enabled by default until bugs around colour accuracy are addressed. Please reconsider enabling AVIF by default until colour is working. This will have long lasting implications for people and services who want to serve AVIF and trust the Accept
header.
Comment 23•3 years ago
|
||
I agree. Are we sure we want to ship this without colorspace support?
Comment 24•3 years ago
|
||
I'm sorry to keep pushing on this so aggressively but the situation is more problematic than I had initially thought.
With the release of Firefox 86 in two days, this needs urgent attention. I would have pushed on this sooner but I was sideswiped by the fact that AVIF support was enabled by default before all the blockers for bug 1443863 were resolved.
AVIF support, as it stands now is too broken to ship.
To recap the situation:
Any image encoded with libheif (used by ImageMagick for example) will have completely inaccurate colour in Firefox. This is clearly visible in attachment 9202460 [details] and discussed in more detail in bug 1634741. This is not a problem with other browsers with AVIF support.
Colour is broken on all displays, both sRGB and wide gamut, and personally observed in both macOS and Linux X11.
These are not esoteric AVIF images or unusual input images. This happens with a plain old JPEG without accompanying ICC profile (the most common kind) encoded to AVIF with default parameters with one of the most common AVIF codecs (libheif/libaom, as used by ImageMagick for example).
The situation is made worse because this version of Firefox will start advertising AVIF support in the Accept
header. In order to properly do content negotiation, servers need to trust the Accept
header and assume that support for anything in the Accept
header is at the lowest common denominator for browsers that advertise that format. If Firefox 86 ships with AVIF enabled today, with advertising in the Accept
header for support, we now must assume that the lowest common denominator has completely inaccurate colour. This means that servers must assume that browsers advertising AVIF support in the Accept
header will have broken colour. The only workaround is to use User-Agent
sniffing to determine real working AVIF support which is completely antithetical to how content negotiation is supposed to work.
Similar issues made the Accept
header useless for years with regards to WebP support in Chrome (around introducing features like transparency, lossless encoding, and animation that older browsers didn't support). Making the same mistake here will have very long lasting repercussions.
Image format "support" with such inaccurate colour is not "support". Rendering an image isn't meaningful if the image is rendered so incorrectly. AVIF in Firefox is not ready.
Look, I'm as excited as anyone for AVIF support in Firefox (it's why I'm pushing so hard here), and can't wait to enable it in our imaging products at Akamai, but enabling it as is today is going to do more harm than good.
Comment 25•3 years ago
|
||
I'm a "nobody", I'm not sure my "vote" counts. But still want to say I agree with Nick. I want AVIF to succeed. To do that we must be able to trust a browser saying it can handle AVIF to show expected colors if we choose to server it AVIF instead of a fallback jpg.
I can easily accept lack of f.ex. animation-support, that's a very special case. But missing proper colorspace handling in 2021, that's a no go.
Comment 26•3 years ago
|
||
Just to be clear, these incorrect colours happen without colour profiles even being involved.
This happens in the most base of base case: untagged JPEG converted to AVIF with default settings using libheif/libaom (with ImageMagick for example) viewed on any display.
Comment 27•3 years ago
|
||
Status update: We talked about not shipping this on Friday, unfortunately it was very late in the release schedule, would have required spinning a new RC and potentially missing the release date. We still have the option of disabling this by a remotely via pref flip and we'll talk about doing that tomorrow.
It, indeed, would've been better if these concerns had been raised earlier instead of after the last RC.
Nick, since Firefox Nightly and Beta have been setting the Accept header for a while, I assume Akamai is not actually serving AVIF based off of that yet?
Comment 28•3 years ago
|
||
Akamai hasn't publicly exposed serving AVIF by the Accept
header yet. Initial support is imminent. We've had to add a block for Firefox in anticipation for the 86 release. Having a misbehaving browser released will complicate matters though because of sensitivity to serving only colour accurate images even to lingering outdated browser versions.
Comment 29•3 years ago
|
||
Also, to be fair, concerns were raised 11 days ago in bug 1634741 and the impact was shrouded by bug 1443863 being still open also with related open blockers.
Comment 30•3 years ago
|
||
Would it make things any better if I can submit a patch to fix the most common cases now?
Comment 31•3 years ago
|
||
Chris, we are not going to ship AVIF in 86 tomorrow, could the dev docs be updated to reflect that? Thanks
Comment 32•3 years ago
|
||
Backed out for 86
https://hg.mozilla.org/releases/mozilla-release/rev/153c0901a573c2684bb83499b73db12fe65e2903
Updated•3 years ago
|
Comment 33•3 years ago
|
||
Thanks :pascalc, I was reading this thread with interest, and waiting for the call on it.
I'll remove mention of it from the release notes and release blog post immediately, and get Hamish to revert any specific mentions in the docs elsewhere.
Assignee | ||
Updated•3 years ago
|
Comment 34•3 years ago
|
||
FYI, docs work "undone" once the fixes are merged. Info about what I changed in https://github.com/mdn/content/issues/1726#issuecomment-783871008. We can re-enable pretty easily by reverting those changes; though at that point you might have added support for animations etc, which would imply a few addition tidy-ups.
Comment 35•3 years ago
|
||
Jon, can you take care of the patch for 87/88? I don't know if we want to keep the feature in nightly and/or early-beta for now, or disabled entirely.
Comment 36•3 years ago
|
||
Disabled in 86 with a backout.
Assignee | ||
Comment 37•3 years ago
|
||
(In reply to Julien Cristau [:jcristau] from comment #35)
Jon, can you take care of the patch for 87/88? I don't know if we want to keep the feature in nightly and/or early-beta for now, or disabled entirely.
I believe everything is set for now (thanks to you, Julien). AVIF remains enabled for Fx87 nightly/beta, but disabled for Fx87 release. Let me know if I'm missing something since this is my first experience with a back-out like this.
We'll shoot for enabling in Fx88 release, but make sure we have the issues that derailed the Fx86 release plan sorted out first.
Comment 38•3 years ago
|
||
87 is currently on mozilla-beta, so AVIF is set to enabled there. I'll keep the needinfo to turn that off later this week.
Comment 39•3 years ago
|
||
I was unable to figure out why Firefox doesn't accept my transparent AVIF images, which do work in Chrome: https://bugzilla.mozilla.org/show_bug.cgi?id=1696056
Comment 40•3 years ago
|
||
uplift |
Now disabled for 87 late beta and release:
https://hg.mozilla.org/releases/mozilla-beta/rev/58cf44cd280ff96c3df220963cc49c8e99b0f03d
Comment 41•3 years ago
|
||
Hi Jon, I just wanted to confirm that we're targeting Fx89 now and want to land the patch from comment 40 on Beta again after 88 merges there on Monday?
Updated•3 years ago
|
Comment 43•3 years ago
|
||
uplift |
Backed out from 88 as well for 88.0b7.
https://hg.mozilla.org/releases/mozilla-beta/rev/ddaaeb918e1f
Given that we plan to let this ride Fx89 to release and we've been handling the disabling by backing out the patch which enabled it by default, I think there's no further action required in this bug.
Comment 44•3 years ago
|
||
This would be easier to track for non-Mozilla people if this bug was not resolved until the blockers this bug depends on are also resolved. AVIF is not ready to ship until those bugs are finished.
![]() |
||
Comment 45•3 years ago
|
||
bugherder uplift |
Assignee | ||
Comment 46•3 years ago
|
||
Hey Nick,
Sorry for the confusion here. The bug is correctly RESOLVED FIXED at the moment because AVIF is currently enabled by default in nightly, and absent intervention will be going through our normal release process to ship in Fx89. Yes, there are incomplete blocking issues and our expectation is that those will be resolved in time for shipping in Fx89. You can rest assured that this bug will get updated in response to any changes to that plan.
Assignee | ||
Comment 47•3 years ago
|
||
Revert this change to turn AVIF off by default for now
Updated•3 years ago
|
Comment 48•3 years ago
|
||
Pushed by jbauman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6646eb3b62f7 Revert Enable AVIF support by default. r=aosmond,valentin,necko-reviewers,preferences-reviewers,Gijs
Comment 49•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 50•3 years ago
|
||
Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!
Comment 51•3 years ago
|
||
(In reply to Punam Dahiya [:pdahiya] from comment #50)
Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!
Uh, if we're disabling avif on nightly by default for 89 (which is what this bug does), I don't think you can rely on it for release, so I would suggest updating the images to not use avif.
Comment 52•3 years ago
|
||
(In reply to :Gijs (he/him) from comment #51)
(In reply to Punam Dahiya [:pdahiya] from comment #50)
Revert of this bug seems to have caused bug 1702250 to regress as it relies on optimized avif image to use as background for MR1 new user onboarding flow. Is there an ETA on fix or uplift of blocking issue into Fx89, we were relying on optimized light weight avif images to show up as part of first about:welcome screen. Thanks!
Uh, if we're disabling avif on nightly by default for 89 (which is what this bug does), I don't think you can rely on it for release, so I would suggest updating the images to not use avif.
Started patch to use webp in Bug 1705499, hopefully we see avif turned on by default in 90
Comment 53•3 years ago
|
||
If even we enable avif by default on release we should not be relying on it in our chrome code until at least one release after the first release with it enabled in case we need to disable it for some critical issue, even if that is unlikely we don't want to have to worry about breaking anything else.
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 54•2 years ago
|
||
Updated•2 years ago
|
Comment 55•2 years ago
|
||
Pushed by jbauman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bb07fcce3567 Enable AVIF support by default. r=jrmuizel,necko-reviewers,preferences-reviewers,valentin,Gijs
Comment 56•2 years ago
|
||
bugherder |
Comment 58•2 years ago
|
||
Shouldn't this wait for bug 1686338 to be resolved? I don't think Firefox should indicate that it supports AVIF if it doesn't support all AVIF files (i.e. animated ones).
Assignee | ||
Comment 59•2 years ago
|
||
What's implemented so far should cover the vast majority of AVIF use cases. We decided it was worth shipping based on what we thought would be most valuable to users and the format as well as provide insight into what unimplemented features we should prioritize based on usage.
Comment 60•2 years ago
|
||
I still don't think this is the right choice. Now Firefox will send Accept: image/avif
when it doesn't support all AVIF files. This means that a site with animated AVIF files will have to look at the user agent or some other information to determine if its files will work for a given user.
Comment 61•2 years ago
|
||
Ok with release without 100% perfect, will never be perfect..
Comment 62•2 years ago
|
||
Obviously it'll never be perfect, but IMO Firefox should at least attempt to support the entire format before declaring that it supports the entire format. Either that or we'd need a way for Firefox to indicate to a website that it only supports non-animated AVIF files.
AVIF being enabled by default was already delayed until colors were fixed, so there is precedent for Firefox developers not wanting to roll out imperfect support for a format. I don't see why it can't wait some more.
Comment 63•2 years ago
|
||
(In reply to benjamin.j.grant from comment #62)
AVIF being enabled by default was already delayed until colors were fixed, so there is precedent for Firefox developers not wanting to roll out imperfect support for a format. I don't see why it can't wait some more.
One could argue that incorrect colors were detrimental to the main use case of this format (serving static images) that is becoming more and more requested. On the other hand animation is a subset of the avif format that is not widely in use (yet) and there is little to gain from putting avif support off -- there are plenty of precedents of not supporting a format fully for the sake of release.
Also that doesn't mean animation won't happen in the future, and I invite you to raise priority on the animation bug if that matter to you.
Good work Firefox team, it's great to see this out.
Comment 64•2 years ago
|
||
(In reply to Vittorio Giovara from comment #63)
On the other hand animation is a subset of the avif format that is not widely in use (yet)
Animated AVIF does have quite some potential, since AFAIK it allows all AV1 features including inter-frame compression. This is in contrast with other animation formats that are intra-only, so AVIF should have much higher efficiency. It's certainly one of the most exciting parts of the format to me, as opposed to lossy still AVIF (which will probably get superseded by JPEG XL for all but low-bpp images) and lossless (which is generally worse than WebP and sometimes even PNG).
there is little to gain from putting avif support off
Rolling out incomplete AVIF support now will make it harder to serve animated AVIFs forever (or as long as the Firefox version(s) that support still-only AVIF are ones you care about supporting), because it puts browsers in the wild that send an incorrect/dishonest Accept: image/avif
header. Delaying support until we have animations will only keep still AVIF at the support level it has now (where it is already somewhat in use, since Chrome and friends support it), and only until Firefox rolls out complete AVIF support. Notably, the latter course of action requires no action from websites serving still or animated AVIF files.
there are plenty of precedents of not supporting a format fully for the sake of release.
I'm not familiar with the history here—could you elaborate?
I should also mention a couple other things:
- IMO a better solution would be differentiating between still and animated AVIF files by MIME type. It sounds like
image/avifs
was proposed for animated files, but they ended up getting the same one. If they had different types, there would be no issue here—Firefox could roll out still-only support withAccept: image/avif
, and browsers that support animations too could sendAccept: image/avif,image/avifs
. I think supporting inter-frame compression makes animated AVIF sufficiently different from still AVIF to merit another MIME type, but I understand there's a process here and a decision was made already. I can't just will a MIME type into existence :_( - Right now, Firefox (I have stable 90.0.2 with
image.avif.enabled
=true
) can actually open animated AVIF files; it just displays the first frame only. This means that if Firefox is served an animated AVIF file, the only way the user could tell that it's animated would be contextual clues. If still-only AVIF support is to be rolled out, I think Firefox should display an error for animated files, so the user could at least tell something is wrong.
Good work Firefox team, it's great to see this out.
Yes, I should have said this earlier. Thank you all for your work supporting still AVIF and other modern image/video formats! I am arguing this point because I want Firefox to be the best it can be.
Comment 65•2 years ago
|
||
benjamin, I understand and respect your frustration about the topic, but this is not the right place to discuss them. Please open separate issues or add your thoughts to the relevant bug reports
Updated•2 years ago
|
Comment 66•2 years ago
|
||
FF92 release docs work for this feature can be tracked in https://github.com/mdn/content/issues/7744#issuecomment-898194268
A few questions. When we last tried to document this in FF86 it was characterised as "basic support only; advanced features like animated images and colorspace support yet to the implemented".
- Is that still correct - if not, what would you say now?
- Other than the problem in FF86 that stopped this going out, have any other major changes/improvements been added?
- I will be updating https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#avif to remove the comments about "behind a preference". If there is anything else you think should go in that table, let me know.
- Does this change have any impact on AV1 support in Android (e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#av1_support_for_firefox_on_android). I assume not - just checking.
FYI, I tried the attachment referred to in https://bugzilla.mozilla.org/show_bug.cgi?id=1682995#c24 and this still doesn't work in FF93 (https://bug1634741.bmoattachments.org/attachment.cgi?id=9202460). FF says "The image cannot be displayed because it contains errors" but Chrome 93 can display it.
Assignee | ||
Comment 67•2 years ago
|
||
A few questions. When we last tried to document this in FF86 it was characterised as "basic support only; advanced features like animated images and colorspace support yet to the implemented".
- Is that still correct - if not, what would you say now?
Image sequences and animation (bug 1686338) aren't supported yet. Colorspace support (bug 1634741) is complete, including both full and limited range (bug 1654461) colors.
- Other than the problem in FF86 that stopped this going out, have any other major changes/improvements been added?
In addition to the colorspace work, image transforms for mirroring and rotation (bug 1696093) have been implemented, as well as a number of under-the-hood changes. Parsing is more conformant to the specifications (bug 1701426), though there's more work coming there. There's also a new pref to adjust the compliance strictness (more on that below).
I will be updating https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types#avif to remove the comments about "behind a preference". If there is anything else you think should go in that table, let me know.
I'd suggest adding the new preference image.avif.compliance_strictness
. It defaults to 1
, which rejects only inputs which violate requirements of the specification ("shall" language), but accepts inputs which violate recommendations ("should" language). This can be turned down to 0
to accept any inputs that we can safely and unambiguously interpret, or turned up to 2
to reject inputs which violate requirements or recommendations (a sort of validator mode).
- Does this change have any impact on AV1 support in Android
No
FYI, I tried the attachment referred to in https://bugzilla.mozilla.org/show_bug.cgi?id=1682995#c24 and this still doesn't work in FF93 (https://bug1634741.bmoattachments.org/attachment.cgi?id=9202460). FF says "The image cannot be displayed because it contains errors" but Chrome 93 can display it.
That file is invalid per the standard due to the omission of the required Pixel Information (pixi) box. This can be checked with the AOM AVIF validator: https://gpac.github.io/ComplianceWarden-wasm/avif.html. It's possible to display it by relaxing the parsing strictness pref. See bug 1725022 for more information.
Updated•2 years ago
|
Assignee | ||
Comment 68•2 years ago
|
||
AVIF support will ship enabled by default in Firefox 92 with compliance strictness temporarily relaxed via bug 1727448.
See bug 1443863 comment 80 for the rationale
Assignee | ||
Comment 69•2 years ago
|
||
Backed out changeset bb07fcce3567
Unfortunately we didn't discover bug 1729071 early enough to fix it and the
impact is likely too great to want to continue with release.
Assignee | ||
Comment 70•2 years ago
|
||
Sadly, we're going to have to pull AVIF by default support for 92. See bug 1729071 comment 4 for the reasoning
Comment 71•2 years ago
|
||
backout uplift |
Backed out for 92.0rc3. It remains enabled by default for 93+. Also moved from the Fx92 to the Fx93 relnotes.
https://hg.mozilla.org/releases/mozilla-release/rev/74a9748f90655e731a34c298948869e67ceaa102
Updated•2 years ago
|
Description
•