AVIF is fantastic format and I use it in my production applications. Spent quite a bit of time looking to the best settings (at least for up to 2k images) and for anyone interested in converting images to AVIF, here's what I've found to work the best for creating the smallest size (10x+ smaller) while still retaining good quality and even supports PNG transparency:
Unfortunately for the comparison-focused blog post the comparison widgets is pretty bad - you can't quickly compare 2 reference pictures (original vs AVIF or original vs JXL) at different scalings like here https://web.archive.org/web/20200915201019/https://afontenot...
(also like the BPP size metric that is picture size-independent)
Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard
(also, "hold" is a rather unergonomic action)
Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up
> libjxl's maximum effort is very slow. It produces files 2–7% smaller than its default for photos, and ~25% smaller for the screenshot and illustration, but takes 9–46 seconds, which is 50–180x as long as its default. jixel gets the same results in a couple of seconds.
libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.
In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).
I've been using AVIF on my blog for a few years. My blog's image corpus is almost entirely videogame screenshots, and I keep the original PNGs so I can re-encode if better encoders release. Despite playing around with JPEGXL every year or so, AVIF images usually looked better (if only a little) at the same file size (vs JPEGXL).
After reading this article, there's something to point to prove I'm not going crazy.
>Animated image formats are dumb and animated JPEG XL is no exception. Video formats are better at video. They're built for it. They're optimised for it. Not just in terms of encoding, but also in terms of playback.
This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.
><video muted autoplay> is right there.
>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.
I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.
Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.
I also didn't know there was another Rust JXL decoder separate from jxl-rs named jixel.[0]
That F1 image is, in my mind, proof of exactly what is wrong with AVIF. If you look closely the beautiful highlights on the car have been erased and replaced with something plausible. Once you see it you can't unsee it and it boggles my mind that people are still using it as an example.
Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.
I'm looking as closely as I'm able, and I don't see what you mean. (I'm not a car guy, or a photo guy.) What do you mean by highlights? What am I looking for? Reflections?
Look between the Eni and ApeCoin logos. In lossless you can see there are lines from what I assume separate pieces assembled together. Next to ApeCoin there's also a round piece in the lossless version which is missing from the AVIF. JPEG XL loses most of these as well though.
That's what I noticed anyway, not a car or photo guy either.
You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.
This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.
The lossless version is JPEG XL, hence the difference to AVIF.
JPEG transcoding is one of the neatest features of JXL; there is so much existing jpeg out there. Eventually that may be unnecessary, but it's looking like this could already save a significant amount of space for photo archive backups for example.
The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
JPEG is a lossy format. JPEG -> AVIF adds a second loss operation. JPEG to JPEG-XL is lossless but with a smaller file size. So one does not further degrade the jpegs beyond what they were already degraded in creating them in the first place.
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and back losslessly - it's just a container change. That's why it performs so much better, because it's built for motion.
So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)
No. I used to think this too, but it isn't limited to keyframes.You can convert an AV1 MP4 to AVIF and back losslessly - even if it has non-keyframes. It's just a different container. It has the full AV1 capability. Plus transparency.
Apologies if your comment was meant to be a parody as there's a bit of Poe's law around this stuff…
IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.
JPEG is fast as fuck, due to it being designed for decades old hardware.
When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.
It'd be interesting to scale this up to a lot of images - and have users blind A/B test, like the LLM Arena on Huggingface which helped filter out "benchmaxxing" vs actual intelligence & utility. Because 1) images can be so diverse* and 2) an intrinsic tradeoff might exist between general efficiency and out-of-distribution robustness.
It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).
* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.
And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.
There was a study done while I was at Google, and I fought for it to be done on high density screens, because that's what most users have. The response was "but people won't be able to see the artifacts" and my head nearly rotated 180 degrees.
But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.
Maybe the first step to designing better encoders is to build an extremely accurate visuoperceptual error metric. Seems like ML's rapid progress haven't caught onto it just yet.
Jake's interest in F1 hasn't waned, which is good to see. I am presuming that picture of an Alpine/Renault at Goodwood is his 18Mb photo, but I could be wrong. Neither has his interest im image compression waned, which is also good to see. But why the move from Google to Firefox?
I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.
Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.
In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.
It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.
I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.
AVIF is a lifesaver for animation with separate transparency layers so the transparency can change position frame by frame. The only other alternative is WebM which has Safari limitations.
But the performance is so bad it isn't worth using. You're better off encoding a double height AV1 and mashing it together with WebGL https://jakearchibald.com/2024/video-with-transparency/. That's how bad the situation is.
Is there an advantage to this as a separate layer compared to just having an alpha channel baked into the image data itself? If not premultiplied then it would not affect the other channels either.
I think one overlooked aspect is that AVIF is container based. Meaning that once sites support, when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
> I think one overlooked aspect is that AVIF is container based.
Many other image formats are. AVIF uses HEIC, the same container that HEIF does.
> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.
The container is useless. Files based on a newer codec won't display anyway.
ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.
AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)
I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.
This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.
My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
You didn't get the point of the post. I explained why and how container matters here. Not a specific container, but just the idea of container itself. Hint, it's not the browser.
AVIF is fantastic format and I use it in my production applications. Spent quite a bit of time looking to the best settings (at least for up to 2k images) and for anyone interested in converting images to AVIF, here's what I've found to work the best for creating the smallest size (10x+ smaller) while still retaining good quality and even supports PNG transparency:
Unfortunately for the comparison-focused blog post the comparison widgets is pretty bad - you can't quickly compare 2 reference pictures (original vs AVIF or original vs JXL) at different scalings like here https://web.archive.org/web/20200915201019/https://afontenot...
(also like the BPP size metric that is picture size-independent)
Wish that widget with improvements (that allows comparison of 3 pics with 3 buttons: original/codec1/codec2) were the widespread standard (also, "hold" is a rather unergonomic action)
Otherwise, seems like AVIF has had impressive gains in both speed and quality, wonder whether JXL could catch up
To be honest it's starting to sound like Google were right and adding JPEG XL support was a mistake.
> libjxl's maximum effort is very slow. It produces files 2–7% smaller than its default for photos, and ~25% smaller for the screenshot and illustration, but takes 9–46 seconds, which is 50–180x as long as its default. jixel gets the same results in a couple of seconds.
libjxl's slow speed at efforts >7 is primarily due to an iterative evaluation-optimization loop of a perceptual error metric called Butteraugli (by tuning quantization weights). This, as well as some other computations in libjxl encoding, happen to be data-parallel and run faster on GPUs than multicore CPUs.
In case anyone is interested, I've been working on a GPU-accelerated libjxl port (supporting CUDA and Metal for now) that makes this much faster, closer to libjxl's normal speeds: https://github.com/yunho-c/gjxl - geared for encoding a large batch images into JPEG XL. It's also faster by around 2.9x at normal effort (7).
I've been using AVIF on my blog for a few years. My blog's image corpus is almost entirely videogame screenshots, and I keep the original PNGs so I can re-encode if better encoders release. Despite playing around with JPEGXL every year or so, AVIF images usually looked better (if only a little) at the same file size (vs JPEGXL).
After reading this article, there's something to point to prove I'm not going crazy.
>Animated image formats are dumb and animated JPEG XL is no exception. Video formats are better at video. They're built for it. They're optimised for it. Not just in terms of encoding, but also in terms of playback.
This is something I've felt doesn't get enough attention when comparing JXL and AVIF. AVIF can be the replacement for GIF.
><video muted autoplay> is right there.
>No, I'm not adding a demo. I don't want it on my server. Use video formats for video.
I'm not sure if "Use video formats for video" is saying to use AVIF over JXL or saying to use AV1 over AVIF. If the latter, GIF-like animations have a different enough user expectation that it makes sense to have it as something different from regular videos. Even <video muted autoplay> doesn't encode the full expected behavior because GIFs are not expected to have controls like pause, play and scrub. And even if you hide the controls users will expect similar behavior when opening it in an image viewer or in a new tab. Images do not have controls so they fit better as an image, although maybe they need their own category.
Also, I didn't realize how good AVIF was at progressive rendering. I don't think I knew it could do that at all. I think AVIF is the clear winner for the web, although it is still nice to have JXL for lossless. Somehow I feel that AVIF still hasn't gained as much usage as it should, especially now that it is supported almost everywhere. I think I see more webp than AVIF, and JPEG is still everywhere. Maybe now that JXL is out, developers will take another look? AVIF is supported by 96.35%-98.83% of browsers according to caniuse whereas webp is 97.18%-99.68% and JPEG is 97.28%-99.78%.
I also didn't know there was another Rust JXL decoder separate from jxl-rs named jixel.[0]
[0] https://github.com/awxkee/jixel
nit: another rust ENCoder, not DE
Though given the lagging speed in decoding, is there a faster tying JXL decoder planned?
That F1 image is, in my mind, proof of exactly what is wrong with AVIF. If you look closely the beautiful highlights on the car have been erased and replaced with something plausible. Once you see it you can't unsee it and it boggles my mind that people are still using it as an example.
Granted, AVIF performs impressively for, say, a huge hero image for a blog where you're out to create an overall impression and people aren't going to look at it closely. It does not impress me when I am compressing photos I took with my mirrorless and I expect them to look like photos taken with a mirrorless and not cell phone snaps.
[delayed]
Would you be able to circle these highlights? I viewed - https://jakearchibald.com/c/original-CXtAofvc.jpg - https://jakearchibald.com/c/avif-q39-e0-d8-yuv444-ssimu70.4-... at 100% magnification at peeped around for a few minutes but didn't notice anything. Maybe my eyes / monitor is bad...
Oh crap, it's this image
https://jakearchibald.com/2020/avif-has-landed/demos/compare...
I was talking about. He linked another one! Guess people finally realized that one sucks and now they have a new one. I screwed up.
They didn't even have the halo back then!
I'm looking as closely as I'm able, and I don't see what you mean. (I'm not a car guy, or a photo guy.) What do you mean by highlights? What am I looking for? Reflections?
Look between the Eni and ApeCoin logos. In lossless you can see there are lines from what I assume separate pieces assembled together. Next to ApeCoin there's also a round piece in the lossless version which is missing from the AVIF. JPEG XL loses most of these as well though.
That's what I noticed anyway, not a car or photo guy either.
I agree fwiw. The only one that looks bad to me is jixel at lower qualities.
OH WAIT. I KNOW WHAT'S HAPPENING HERE.
You're looking at it in a browser that doesn't support JPEG XL, so it's falling back to a WASM renderer, and I think it handles resizing differently.
This is totally my bad. I thought I was doing a good thing by adding that fallback renderer, but it isn't identical and it's giving people the wrong impression.
The lossless version is JPEG XL, hence the difference to AVIF.
by the way, why not convert everything to png for comparisons to avoid browser support issues?
JPEG transcoding is one of the neatest features of JXL; there is so much existing jpeg out there. Eventually that may be unnecessary, but it's looking like this could already save a significant amount of space for photo archive backups for example.
That's just by changing the entropy coder and retaining the DCT coefficients. The idea is similar to Dropbox's Lepton. https://dropbox.tech/infrastructure/lepton-image-compression...
The main difference being that Lepton is worse and 100x slower.
Great article!
Overall I am getting that AVIF is better on the web...unless Lossless is needed, in that case better take JPEGXL.
The question now is how much of AVIF's advantage comes from the encoder compared to the image format itself. If it is the encoder, does JPEG XL even stand a chance of catching up? AVIF will certainly receive further improvements, albeit at a diminishing rate.
https://giannirosato.com/blog/post/case-against-jxl/ suggests JXL is fundamentally limited. We'll see. There's a race on and it's great!
I'm only casually following JPEG-XL and my impression from previous reading here on HN was that JPEG-XL was the best solution available for a wide variety of usecases, but it looks like numbers dont match that claim?
Claims around JPEG XL have always been wild. E.g. this from one of the creators https://x.com/jyzg/status/1592811472073416704
That's.. horrific. How can someone be this out of touch?
JPEG-XL can be a quick win since it is possible to do a transcode of all of your existing ('classic') JPEG files with zero (visual) losses in quality.
If you're transcoding why wont you go to avif or another one? If jpeg -> jpeg-xl uniquely better?
JPEG is a lossy format. JPEG -> AVIF adds a second loss operation. JPEG to JPEG-XL is lossless but with a smaller file size. So one does not further degrade the jpegs beyond what they were already degraded in creating them in the first place.
> AVIF is basically the keyframe format of AV1 video, with a bunch of still-image-specific optimisations thrown in. Animated AVIF however, is pretty much just a repackaging of AV1 video. You can convert an AV1 MP4 to AVIF and back losslessly - it's just a container change. That's why it performs so much better, because it's built for motion.
So, is animated AVIF only keyframes / p-frames, where each frame is independent from the other? I was under that impression, uncertain if there are any other capabilities it might have (like only updating part of the canvas when only parts change, like GIF supports)
No. I used to think this too, but it isn't limited to keyframes.You can convert an AV1 MP4 to AVIF and back losslessly - even if it has non-keyframes. It's just a different container. It has the full AV1 capability. Plus transparency.
Perhaps useful:
* https://caniuse.com/?search=avif
* https://caniuse.com/?search=jpegxl
Note about caniuse: browsers dragged their feet with jpegxl while avif had the backing of the biggest browser in existence: internet explorer
Apologies if your comment was meant to be a parody as there's a bit of Poe's law around this stuff…
IE never supported AVIF. Edge even shipped AVIF later than Chrome. One of the leaders of JPEG XL worked at Google until relatively recently. A massive amount of JPEG XL development has been done by a team at Google.
1. How long does size, encode time and resize take compared to good old jpeg?
2. Is it possible to encode AVIF with hardware acceleration?
JPEG is fast as fuck, due to it being designed for decades old hardware.
When it comes to hardware encoders, the nicest thing you can say about them is they're fast. Software tends to do way better at quality. Hardware AV1 encoders will be tuned for video rather than stills.
It'd be interesting to scale this up to a lot of images - and have users blind A/B test, like the LLM Arena on Huggingface which helped filter out "benchmaxxing" vs actual intelligence & utility. Because 1) images can be so diverse* and 2) an intrinsic tradeoff might exist between general efficiency and out-of-distribution robustness.
It's hard to rigorously judge a codec from a handful images, especially given the large impact they would have (with a widely adopted codec encoding bazillions of images in the coming years).
* There are many intricate details that go into codecs and visual perception. For instance, our sensitivity to visual errors are dependent on colors (all of hue, saturation, and brightness), spatial frequency of artifacts, local contrast and texture presence, et cetera.
And like OP mentioned, perceptual error metrics (including SSIMULACRA2) aren't perfectly representative of human-evaluated visual quality. For instance, libjxl deliberately makes choices that hurt SSIMU2 scores, but improve human-rated quality.
There was a study done while I was at Google, and I fought for it to be done on high density screens, because that's what most users have. The response was "but people won't be able to see the artifacts" and my head nearly rotated 180 degrees.
But yes, you can see this with jixel, which I'm really impressed by, but it's so tuned to SSIMU2 that it looks really bad to human eyes in some cases compared to libjxl.
I feel that!
Maybe the first step to designing better encoders is to build an extremely accurate visuoperceptual error metric. Seems like ML's rapid progress haven't caught onto it just yet.
I really hope that some day Firefox supports HDR AVIF images
It's not AVIF that's the issue, the blocker is supporting HDR in general.
Fair point. HDR images in Firefox just do not work at all, regardless of the format.
Most of these images are not at 100%. Use large images and show 100% crops everywhere.
Jake's interest in F1 hasn't waned, which is good to see. I am presuming that picture of an Alpine/Renault at Goodwood is his 18Mb photo, but I could be wrong. Neither has his interest im image compression waned, which is also good to see. But why the move from Google to Firefox?
I am still on webp, thinking that I am on the bleeding edge in a world where artworkers are obsessed with pixels with JPG/PNG as the only formats they know, which is an advance on GIF.
Every browser advertises what formats it will accept and if it is in 'data-saving, low bandwidth mode', so I just configure the CDN to keep the names the same '.jpg' but to send the bestest format for the situation/browser, whether that be webp or AVIF, fetching super-high resolution files from the origin server, outputting them in 'retina' resolution with none of those 'picture' elements referencing half a dozen 'responsive' sizes.
In this way nobody has to care what image format is being served, and if it is deemed that everything is way too compressed, the CDN can be flushed of the cached images, quality increased, and cache rebuilt.
It looks like I will need to update my server configuration to use JPEG XL in the usual five years' time, given the lack of any revolutionary benefit.
Yep, Alpine, and yep, Goodwood! Nicely done!
I was at Google for 10 years, then went to Shopify for 2 years, but I missed the web. For most of the time I was at Google, it mostly did what was good for the web, rather than pushing Google's interests, but that started to change, which is one of things that led to me leaving. E.g. see what happened with the Prompt API.
AVIF is a lifesaver for animation with separate transparency layers so the transparency can change position frame by frame. The only other alternative is WebM which has Safari limitations.
But the performance is so bad it isn't worth using. You're better off encoding a double height AV1 and mashing it together with WebGL https://jakearchibald.com/2024/video-with-transparency/. That's how bad the situation is.
Is there an advantage to this as a separate layer compared to just having an alpha channel baked into the image data itself? If not premultiplied then it would not affect the other channels either.
Ah, Chrome ships JXL when we already have a better codec for the web!
PDF standardized on JPEG XL, and Chrome ships with a PDF renderer.
I think one overlooked aspect is that AVIF is container based. Meaning that once sites support, when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
> I think one overlooked aspect is that AVIF is container based.
Many other image formats are. AVIF uses HEIC, the same container that HEIF does.
> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.
https://github.com/AOMediaCodec/av2-isobmff
The container is useless. Files based on a newer codec won't display anyway.
ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.
AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)
I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.
This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.
I don't think so. WebM doesn't need new content type and it can ship AV1 and VP9 all the same.
What are you talking about? Video formats have a whole mad type parameter for this stuff https://jakearchibald.com/2022/html-codecs-parameter-for-av1...
Can someone please explain the downvotes?
My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
You didn't get the point of the post. I explained why and how container matters here. Not a specific container, but just the idea of container itself. Hint, it's not the browser.