I understand the point you're trying to make, but I think I can at least sort of understand why they're going with this speed of release cadence. If the release cadence is too slow, you might end up with another JPEG situation where the new codec is undeniably better in every way, but nobody wants to implement it since the old standard was around for so long without any competition.
If you're going to do that, then the new thing must be so much better than the old thing that makes the pain of switching to the new thing worth while.
By the time h.265 encoding was trying to gain traction, h.264 encoding speeds were very fast. The image improvement was negligible with the main benefit being smaller file sizes. For the average user, the increased encoding times did not justify that. The switch from MPEG-2 to h.264 had very noticeable quality improvements so it did make it worth while for the slower encodes until h.264 was locked and key code included in CPUs. It was similar to the adoption rates of DVD from VHS compared to Blu-ray from DVD.
> For the average user, the increased encoding times did not justify that.
The average user is a consumer of media, not doing encoding themselves. A one time cost for higher encoding to save bandwidth / storage space many times over is almost always going to make some amount of sense.
The real issue here is just a standard chicken-and-egg problem. To use a new codec, you need it to be supported in end user devices. To get it to be supported, you need to show demand... for a thing that nobody can use yet.
The switch from MPEG-2 to H.264 had that in droves with the cable companies updating their set top boxes. That was enough demand to drive hardware development. I don't know how many people have cut the cord as I haven't played in that field to see numbers in quite some time. I'm guessing there won't be a big push to switch out boxes to support AV2. Even shiny round disc sales are plummeting to the point there's not really a need for an at home player to use it either. This really feels like something for streaming only. Those can all be software decoders. Hopefully, they can make it work well on efficiency cores and not require GPU cores for decode. As you say, vast majority of people won't need to encode so sure make a GPU encoder
The modern set top box / dvd player is the chromecast/firestick/roku/smart tv. They lack the power to do software decoding so they NEED the hardware support. The video platforms want them to upgrade because it'll reduce their costs. Sometimes the same company owns both the platform and the streaming device, which should get things moving even faster.
Sample size of one, but I always have preferred and continue to torrent h265 releases specifically for the amazing quality:size ratio, basically since they were available.
> The image improvement was negligible with the main benefit being smaller file sizes.
That's a contradiction because quality improvement and file size improvement are just two sides of the same coin. You can't have a large quality improvement at the same bit rate without having a large file size reduction at the same quality.
Yes, I stipulate your point, but people are not looking for better encodes at the same bit rate. They are only looking for not worse quality at much lower bit rate. One project I was working on had a hard file size limitation, and switching to h.265 was able to get the size under the limit. At one point, I was told to make it smaller by X MBs. The image wasn't even being looked at with each change. This is why I make the distinction the way that I did.
Another reason to get a new video codec standard finalized sooner is that hardware implementation and deployment in mass market consumer SOCs is glacially slow. On the software side, encoder and decoder performance tends to improve meaningfully in the first few years as optimization occurs. And those running large media distribution platforms prefer at least 12-18 months to evaluate and implement a new codec.
h266 (aka VVC) is seemingly ~~late in development~~ (edit: It has been released but doesn't have much hardware uptake yet). They probably want to ensure that people are aware that it will be matched so that they don't commit to it and AV2 ends up a bit late to the party like AV1 is compared to h265 where it had a notable compatibility lead.
If people know that AV2 is coming and competitive they may avoid adopting h266 and wait for the open alternative to ship.
AV1 competes with h266. They were released near the same date. In many ways h266 has already lost the battle as nobody supports it even though it's been around just as long as AV1.
h267 is still in development and due to be released in 2028. That's the actual competitor with AV2.
I guess it depends how you looked at it. Performance-wise AV1 seems more similar to h265. Hardware support wise h266 seems to have only had shipping hardware this year?
So I guess neither of these line up 1:1. I tend to see h265 and AV1 competing pretty hard right now so I tend to think of those as one generation and presumably h266 and AV2 will compete as the next generation.
The way MPEG runs things there are some oddness with the likes of H265. MPEG likes to add little extensions to a codec over time. That's why H265 was first released in 2013 but ultimately had like 10 different extensions after that fact (the last one in 2024).
AV1 and VP9/VP8 before that have, in contrast, been pretty much static after they were released. AV1 has had a single errata after it's release.
So I could see why you'd see H265 as the competitor. I mostly don't simply because I believe they explicitly stated that they were trying to be competitive with 266.
I personally prefer the way AOMedia is running things and I suspect hardware manufacturers do as well. No licenses and AOM is creating open source reference encoders/decoders. They are working very hard to make it easy for manufacturers to be able to pick up the spec and run with it. Keeping the stream standard static for a long period also means manufacturers don't have to worry that they won't get a new extension next year. Content encoders are also reasonably guaranteed that their encoding with today's software still works with yesteryear hardware.
MPEG, on the other hand, is paywalling the crap out of everything.
> So I could see why you'd see H265 as the competitor. I mostly don't simply because I believe they explicitly stated that they were trying to be competitive with 266.
That is some major revisionist history.
AV1 was created to suck all the oxygen out of the room for h265, and hopefully be finished soon enough that most chipsets would implement AV1 instead of h265, because no one would want to pay the royalty fees. This would then be a major boon to Google, Facebook, Microsoft, Netflix and Amazon. Only Apple had vested interest in h265.
Instead, h265 was finished very fast and Apple almost immediately implemented it on their iPhone chipsets, with their end goal being much smaller video recording sizes at high resolution and FPS. Then Intel added h265 decode to Quick Sync. This was the nail in the coffin for AV1. AV1 is only now seeing some limited uptake.
Hopefully AV2 can have its bitstream / spec frozen in time and garner hardware support before h266 does, otherwise the AV codecs will be forever niche because the MPEG group will always have the lead in hardware decode.
VVC isn't being considered for the internet by any western companies, but it's already gotten significant adoption by the Chinese companies that developed it.
Anyone can participate, yes. For H.266, many of the big H.265 contributors didn't participate as much while Huawei, Tencent, Bytedance, Alibaba, etc. stepped up their contributions significantly. The bulk of the new coding tools were developed by them I believe.
That is what I have been saying for close to 10 years now. We are quite close to Patents free H.264 High Profile.
You will always have to provide H.264 as baseline due to compatibility. And that has a cost of storage. Bandwidth cost have been declining fast, and with AI Capex it doesn't seems to be slowing down either. Meanwhile Storage cost hasn't drop, if anything recent trend suggest it may have plateau and went up for HDD.
H.264 1080P 2Mbps is good enough for a lot of things. Just like how MPEG-2 is still getting encoder improvement ~30 years later so is H.264 encoder.
There are other codec like LCEVC which you can apply on top of H.264 can provide up to 60% bitrate reduction for 4K content. This saves on storage cost and provide enough benefits.
It is only in streaming services like Netflix where the catalog of video are low enough they could afford to re-encode it every 5- 8 months and storage cost is minimal.
Again a new codec introduction is easily a 10 years task. Higher Speed PON is already being tested, while others are working on NGS-PON2 roll out. 5G Home Broadband with Massive MIMO. The true free and open Video Codec may not be AV1 or AV2, but H.264.
I do. I watch scifi shows over the internet with my friends. We watch it together on a web page with an html5 video element served out of my apartment. I've had to re-encode it to 3 megabits per second (to avoid stutter/buffering) with no b-frames. When initially setting it up, I tested both H264 and AV1 at that bitrate and H264 looked considerably worse. No surprise there, considering H264 is old enough to drink (22 years) whereas AV1 is only 7 years old.
Media companies want to save on bandwidth, content types keep changing (e.g. HDR), people want live calls to work whenever, and so on as well. At the same time, GIF still isn't completely gone either just because people needed more than what GIF could give them.
It would be great if AV1 was as ubiquitous as H.264. Apple is very much holding things back by insisting that Safari only support AV1 on devices with hardware decoding (M3 and higher), even though other browsers use software decoding just fine.
(Safari has a low market share but I have an above-average number of Mac / Safari users using my site)
I suspect (with no inside knowledge) that this is a battery life play. CPU decoding == bye bye battery. It is much better to force the server to serve you something that you CAN hardware-decode.
For AV1 this is true, but we don't really need to postulate about whether or not Apple plays games to suppress open codecs, they do it constantly. Like when they finally eventually added support for Opus, but not Ogg containers, so you had to stuff Opus in a CAF that only Safari can support. Opus is also now supported in WebM, but you still can't just decode Ogg Opus, and there is still no sensible audio-only Opus container supported in Safari right now.
Apple devices have had accelerated VP9 devices for literally years, which didn't stop them from simply not supporting VP9 during that time period, despite no reason (i.e. battery life) and despite that it has been patent unencumbered for that entire period.
And so much for battery life... If you are on a Wikimedia website on an iPad, it will use open codecs no matter what, and if you are on an Apple device, you might just get a software decoder in WebAssembly instead, if you're not on a new enough OS.
It's really hard to keep up with Apple's support for open codecs: it's always bad, and it always improves one minor step per year at best. Evidently, I'm behind on it, because I've mostly given up on trying to make software I work on work well with Apple devices by this point. (I can't tell you exactly what's wrong, but I've noticed I still can't get most WebMs to load in Safari on my M1-based iPad... some of them do, some of them do not.)
Apple is hopefully noticing that while major publishers can be swayed by this sort of behavior, lack of support for open codecs and open formats is going to make the iPhone and iPad web experience much worse for people who veer outside of the mainstream for a bit.
Perfect. Apple can implement efficient decode in current/next gen devices then enable support in iOS Safari/WKWebView to chew up battery life of older devices. It's more defensible than Batterygate[0]. For current transition, Liquid Glass might be enough extra load.
If that were the only reason, Apple wouldn't have waited until the M3 chip to include an ASIC for AV1. Other chip manufacturers had AV1 support significantly earlier.
The tech was surely locked down long ago if they're close to announcing, but just putting the dream out there that AV2 makes next-gen image compression more practical. AVIF's very effective at maintaining OK quality at low bitrates, but encoding at high quality on CPU (something like the common ~2bpp JPEG) was very slow. I think that slowed down adoption and was one of the reasons JXL still had a niche. Progressive mode would help for images too.
Another great thing JXL has is lossless recompression of .jpg files, which is a smaller improvement than a whole new format, but much easier to deploy. Saving 22% beats saving 0%. Harder, of course, to see how that one would connect to any of AOMedia's other priorities.
> Is this intended to be competitive with h.266/VVC? And is it?
Yes:
> VVC is not alone in the video coding race. AV1, backed by AOMedia, has already gained traction, although its performance does not make it a direct competitor to VVC in high-end applications. The upcoming AV2, as well as AI-driven encoding techniques, could pose challenges to VVC’s success. Nevertheless, VVC’s strong technical foundation, industry support, and clear intellectual property structure position it as a promising long-term solution for video coding.
> For businesses focused on reducing operational costs, this is a key point in the h.266 vs av1 debate. While the H.266/VVC codec offers powerful compression improvements over h.265, AV1—and eventually AV2—may be more attractive thanks to simpler licensing and long-term affordability.
In terms of pure compression ratio AV1 compete mostly with h265/HVEC in most cases. It does perform pretty well for low bitrate and specific situation like synthetic noise, but h265 is usually better for higher bitrate situations. Hopefully, AV2 will be able to compete with the future H267.
But to be honest, video codec have gotten so good these days, I just hope that we get a reasonably fast open-source encoder. AV1 and HVEC can already turn a 50Go bluray into an almost visually lossless 5~3Go file.
VVC is better than AV1 even before massive amount of tuning. The actual VVC spec including conformance finished in 2022. While for AV1 was 2018.
And H.267 ECM is miles ahead of AV2. There are not even in the same category as AOM has stated AV2 intends for 1080P and efficiency. While ECM at its current form is 50x to 100x slower than VVC encode, and 8 - 10x slower to decode. I am not even sure if it will ever be useable.
I implemented an encoding pipeline for AV1 for vids uploaded to my social news site (think reddit competitor except I'm extremely small fry). I eventually removed the code for it.
While the space savings and quality improvements are good, the encoding speed is an order of magnitude slower than using h264/vp9. In the end the user experience of causing people to wait significantly longer for an AV1 encode wasn't worth the tradeoff. To fix the user experience problem, I still had to encode a h264 version anyway, which kinda defeats the point when it comes to space savings. You still get data transfer improvements, but the break even point for when the encoding costs offset the data transfer costs were around 1000 views per min of video encoded, and as an average I'm far below that.
IMO there's a reason why YouTube only encodes AV1 for certain videos - I suspect it's based off of a view count. Past that point they trigger a AV1 encode, but it isn't worth it to do all videos, at least right now.
Worth keeping in mind I was looking at this ~2 years ago, so things may have evolved since then.
>IMO there's a reason why YouTube only encodes AV1 for certain videos - I suspect it's based off of a view count. Past that point they trigger a AV1 encode, but it isn't worth it to do all videos, at least right now.
But how can they do that without storing the original uploaded video until it hits that view count?
Do they actually store the original uploaded video somewhere, but reencode for the edge servers to save data/storage?
AV1 is really one of those things born out of internet providers (e.g. Google, Amazon) put together so they can deliver content more efficiently with their bandwidth without needing to deal with a complicated web of royalties in addition to paying said royalties. There's plenty of people using AV1 or it's image format but don't realize it.
Also, video encoding pretty much always comes with the tradeoff of more efficient = uses more processing power
I did some testing with the 3 main AV1 encoders with gifs (avif). They’re pretty good. But not as good as jpeg xl but currently basically only Safari supports it.
For most “normie” use cases, I’d recommend cloudflares image transforms which are available on free tier. I actually wrote a small Jekyll plugin for my site to auto prefix images with their transform. Idk why but shipping optimized images is just one of those things that tickles me!
In my experience (not professional, encoding various files for archiving or sharing), AV1 perform quite well for low bitrate situation/streaming, and the encoder is reasonably fast (not as fast as h264 ofc, but that's decades of work on it).
But for higher quality encoding, I personally found that h265/HVEC almost always beat it, with similar encoding time.
As for AV2, I just hope that we get a good open-source encoder.
Totally different goal, but I wish there was a liberatory/non/less-encumbered form for realtime video production too.
A lot of good streaming hardware does jpeg-xs, ISO/IEC 21122, for real-time encoding basically from the camera to the mix station. It's still extremely high bit-rate mostly, but very low latencies.
https://en.wikipedia.org/wiki/JPEG_XS
"AV1 adoption is accelerating"
But before it is widely used and accepted, here's AV2 for you to have compatibility issues with in the wild
With the ubiquity of h.264 and the patents expiring, will anyone but streamers care?
I understand the point you're trying to make, but I think I can at least sort of understand why they're going with this speed of release cadence. If the release cadence is too slow, you might end up with another JPEG situation where the new codec is undeniably better in every way, but nobody wants to implement it since the old standard was around for so long without any competition.
If you're going to do that, then the new thing must be so much better than the old thing that makes the pain of switching to the new thing worth while.
By the time h.265 encoding was trying to gain traction, h.264 encoding speeds were very fast. The image improvement was negligible with the main benefit being smaller file sizes. For the average user, the increased encoding times did not justify that. The switch from MPEG-2 to h.264 had very noticeable quality improvements so it did make it worth while for the slower encodes until h.264 was locked and key code included in CPUs. It was similar to the adoption rates of DVD from VHS compared to Blu-ray from DVD.
> For the average user, the increased encoding times did not justify that.
The average user is a consumer of media, not doing encoding themselves. A one time cost for higher encoding to save bandwidth / storage space many times over is almost always going to make some amount of sense.
The real issue here is just a standard chicken-and-egg problem. To use a new codec, you need it to be supported in end user devices. To get it to be supported, you need to show demand... for a thing that nobody can use yet.
The switch from MPEG-2 to H.264 had that in droves with the cable companies updating their set top boxes. That was enough demand to drive hardware development. I don't know how many people have cut the cord as I haven't played in that field to see numbers in quite some time. I'm guessing there won't be a big push to switch out boxes to support AV2. Even shiny round disc sales are plummeting to the point there's not really a need for an at home player to use it either. This really feels like something for streaming only. Those can all be software decoders. Hopefully, they can make it work well on efficiency cores and not require GPU cores for decode. As you say, vast majority of people won't need to encode so sure make a GPU encoder
The modern set top box / dvd player is the chromecast/firestick/roku/smart tv. They lack the power to do software decoding so they NEED the hardware support. The video platforms want them to upgrade because it'll reduce their costs. Sometimes the same company owns both the platform and the streaming device, which should get things moving even faster.
Sample size of one, but I always have preferred and continue to torrent h265 releases specifically for the amazing quality:size ratio, basically since they were available.
> The image improvement was negligible with the main benefit being smaller file sizes.
That's a contradiction because quality improvement and file size improvement are just two sides of the same coin. You can't have a large quality improvement at the same bit rate without having a large file size reduction at the same quality.
Yes, I stipulate your point, but people are not looking for better encodes at the same bit rate. They are only looking for not worse quality at much lower bit rate. One project I was working on had a hard file size limitation, and switching to h.265 was able to get the size under the limit. At one point, I was told to make it smaller by X MBs. The image wasn't even being looked at with each change. This is why I make the distinction the way that I did.
> If the release cadence is too slow...
Another reason to get a new video codec standard finalized sooner is that hardware implementation and deployment in mass market consumer SOCs is glacially slow. On the software side, encoder and decoder performance tends to improve meaningfully in the first few years as optimization occurs. And those running large media distribution platforms prefer at least 12-18 months to evaluate and implement a new codec.
> […] but nobody wants to implement it since the old standard was around for so long without any competition.
Perhaps:
* https://en.wikipedia.org/wiki/Lindy_effect
h266 (aka VVC) is seemingly ~~late in development~~ (edit: It has been released but doesn't have much hardware uptake yet). They probably want to ensure that people are aware that it will be matched so that they don't commit to it and AV2 ends up a bit late to the party like AV1 is compared to h265 where it had a notable compatibility lead.
If people know that AV2 is coming and competitive they may avoid adopting h266 and wait for the open alternative to ship.
AV1 competes with h266. They were released near the same date. In many ways h266 has already lost the battle as nobody supports it even though it's been around just as long as AV1.
h267 is still in development and due to be released in 2028. That's the actual competitor with AV2.
I guess it depends how you looked at it. Performance-wise AV1 seems more similar to h265. Hardware support wise h266 seems to have only had shipping hardware this year?
So I guess neither of these line up 1:1. I tend to see h265 and AV1 competing pretty hard right now so I tend to think of those as one generation and presumably h266 and AV2 will compete as the next generation.
The way MPEG runs things there are some oddness with the likes of H265. MPEG likes to add little extensions to a codec over time. That's why H265 was first released in 2013 but ultimately had like 10 different extensions after that fact (the last one in 2024).
AV1 and VP9/VP8 before that have, in contrast, been pretty much static after they were released. AV1 has had a single errata after it's release.
So I could see why you'd see H265 as the competitor. I mostly don't simply because I believe they explicitly stated that they were trying to be competitive with 266.
I personally prefer the way AOMedia is running things and I suspect hardware manufacturers do as well. No licenses and AOM is creating open source reference encoders/decoders. They are working very hard to make it easy for manufacturers to be able to pick up the spec and run with it. Keeping the stream standard static for a long period also means manufacturers don't have to worry that they won't get a new extension next year. Content encoders are also reasonably guaranteed that their encoding with today's software still works with yesteryear hardware.
MPEG, on the other hand, is paywalling the crap out of everything.
> So I could see why you'd see H265 as the competitor. I mostly don't simply because I believe they explicitly stated that they were trying to be competitive with 266.
That is some major revisionist history.
AV1 was created to suck all the oxygen out of the room for h265, and hopefully be finished soon enough that most chipsets would implement AV1 instead of h265, because no one would want to pay the royalty fees. This would then be a major boon to Google, Facebook, Microsoft, Netflix and Amazon. Only Apple had vested interest in h265.
Instead, h265 was finished very fast and Apple almost immediately implemented it on their iPhone chipsets, with their end goal being much smaller video recording sizes at high resolution and FPS. Then Intel added h265 decode to Quick Sync. This was the nail in the coffin for AV1. AV1 is only now seeing some limited uptake.
Hopefully AV2 can have its bitstream / spec frozen in time and garner hardware support before h266 does, otherwise the AV codecs will be forever niche because the MPEG group will always have the lead in hardware decode.
VVC isn't being considered for the internet by any western companies, but it's already gotten significant adoption by the Chinese companies that developed it.
That's a weird pull. AFAIK the MPEG group is international. Broadcom, AFAIK, is the biggest pusher of VVC and they are American.
Anyone can participate, yes. For H.266, many of the big H.265 contributors didn't participate as much while Huawei, Tencent, Bytedance, Alibaba, etc. stepped up their contributions significantly. The bulk of the new coding tools were developed by them I believe.
> If people know that AV2 is coming and competitive they may avoid adopting h266 and wait for the open alternative to ship.
But why hurry ? AV3 will come soon and it will be better. /s
That is what I have been saying for close to 10 years now. We are quite close to Patents free H.264 High Profile.
You will always have to provide H.264 as baseline due to compatibility. And that has a cost of storage. Bandwidth cost have been declining fast, and with AI Capex it doesn't seems to be slowing down either. Meanwhile Storage cost hasn't drop, if anything recent trend suggest it may have plateau and went up for HDD.
H.264 1080P 2Mbps is good enough for a lot of things. Just like how MPEG-2 is still getting encoder improvement ~30 years later so is H.264 encoder.
There are other codec like LCEVC which you can apply on top of H.264 can provide up to 60% bitrate reduction for 4K content. This saves on storage cost and provide enough benefits.
It is only in streaming services like Netflix where the catalog of video are low enough they could afford to re-encode it every 5- 8 months and storage cost is minimal.
Again a new codec introduction is easily a 10 years task. Higher Speed PON is already being tested, while others are working on NGS-PON2 roll out. 5G Home Broadband with Massive MIMO. The true free and open Video Codec may not be AV1 or AV2, but H.264.
I do. I watch scifi shows over the internet with my friends. We watch it together on a web page with an html5 video element served out of my apartment. I've had to re-encode it to 3 megabits per second (to avoid stutter/buffering) with no b-frames. When initially setting it up, I tested both H264 and AV1 at that bitrate and H264 looked considerably worse. No surprise there, considering H264 is old enough to drink (22 years) whereas AV1 is only 7 years old.
Media companies want to save on bandwidth, content types keep changing (e.g. HDR), people want live calls to work whenever, and so on as well. At the same time, GIF still isn't completely gone either just because people needed more than what GIF could give them.
It would be great if AV1 was as ubiquitous as H.264. Apple is very much holding things back by insisting that Safari only support AV1 on devices with hardware decoding (M3 and higher), even though other browsers use software decoding just fine.
(Safari has a low market share but I have an above-average number of Mac / Safari users using my site)
h264 is 22 years old as well. AV1 is only seven!
>Safari has a low market share
That is 1.6B iPhone + iPad. I wouldn't say that is low market share. It still have 25-30% of devices.
I suspect (with no inside knowledge) that this is a battery life play. CPU decoding == bye bye battery. It is much better to force the server to serve you something that you CAN hardware-decode.
For AV1 this is true, but we don't really need to postulate about whether or not Apple plays games to suppress open codecs, they do it constantly. Like when they finally eventually added support for Opus, but not Ogg containers, so you had to stuff Opus in a CAF that only Safari can support. Opus is also now supported in WebM, but you still can't just decode Ogg Opus, and there is still no sensible audio-only Opus container supported in Safari right now.
Apple devices have had accelerated VP9 devices for literally years, which didn't stop them from simply not supporting VP9 during that time period, despite no reason (i.e. battery life) and despite that it has been patent unencumbered for that entire period.
And so much for battery life... If you are on a Wikimedia website on an iPad, it will use open codecs no matter what, and if you are on an Apple device, you might just get a software decoder in WebAssembly instead, if you're not on a new enough OS.
> Opus is also now supported in WebM, but you still can't just decode Ogg Opus
Apparently Ogg Opus and Ogg Vorbis has been supported since 18.4 (Mar 2025)[1]
I think it would be great to see more adoption of Opus in podcasting personally.
[1]: https://developer.apple.com/documentation/safari-release-not...
It's really hard to keep up with Apple's support for open codecs: it's always bad, and it always improves one minor step per year at best. Evidently, I'm behind on it, because I've mostly given up on trying to make software I work on work well with Apple devices by this point. (I can't tell you exactly what's wrong, but I've noticed I still can't get most WebMs to load in Safari on my M1-based iPad... some of them do, some of them do not.)
Apple is hopefully noticing that while major publishers can be swayed by this sort of behavior, lack of support for open codecs and open formats is going to make the iPhone and iPad web experience much worse for people who veer outside of the mainstream for a bit.
Perfect. Apple can implement efficient decode in current/next gen devices then enable support in iOS Safari/WKWebView to chew up battery life of older devices. It's more defensible than Batterygate[0]. For current transition, Liquid Glass might be enough extra load.
[0] https://en.wikipedia.org/wiki/Batterygate
If that were the only reason, Apple wouldn't have waited until the M3 chip to include an ASIC for AV1. Other chip manufacturers had AV1 support significantly earlier.
The tech was surely locked down long ago if they're close to announcing, but just putting the dream out there that AV2 makes next-gen image compression more practical. AVIF's very effective at maintaining OK quality at low bitrates, but encoding at high quality on CPU (something like the common ~2bpp JPEG) was very slow. I think that slowed down adoption and was one of the reasons JXL still had a niche. Progressive mode would help for images too.
Another great thing JXL has is lossless recompression of .jpg files, which is a smaller improvement than a whole new format, but much easier to deploy. Saving 22% beats saving 0%. Harder, of course, to see how that one would connect to any of AOMedia's other priorities.
Is this intended to be competitive with h.266/VVC? And is it?
> Is this intended to be competitive with h.266/VVC? And is it?
Yes:
> VVC is not alone in the video coding race. AV1, backed by AOMedia, has already gained traction, although its performance does not make it a direct competitor to VVC in high-end applications. The upcoming AV2, as well as AI-driven encoding techniques, could pose challenges to VVC’s success. Nevertheless, VVC’s strong technical foundation, industry support, and clear intellectual property structure position it as a promising long-term solution for video coding.
* https://www.nokia.com/blog/the-future-of-video-compression-i...
> For businesses focused on reducing operational costs, this is a key point in the h.266 vs av1 debate. While the H.266/VVC codec offers powerful compression improvements over h.265, AV1—and eventually AV2—may be more attractive thanks to simpler licensing and long-term affordability.
* https://www.dacast.com/blog/h266-vvc-versatile-video-coding/
Not qualified to answer.
AV1 competes with VVC. AV2 will be competitive with h.267
In terms of pure compression ratio AV1 compete mostly with h265/HVEC in most cases. It does perform pretty well for low bitrate and specific situation like synthetic noise, but h265 is usually better for higher bitrate situations. Hopefully, AV2 will be able to compete with the future H267.
But to be honest, video codec have gotten so good these days, I just hope that we get a reasonably fast open-source encoder. AV1 and HVEC can already turn a 50Go bluray into an almost visually lossless 5~3Go file.
Go? I haven't see this particular unit before.
Force of habit, o is octet, the French equivalent of bytes.
I believe it originates as the French translation of Gb
VVC is better than AV1 even before massive amount of tuning. The actual VVC spec including conformance finished in 2022. While for AV1 was 2018.
And H.267 ECM is miles ahead of AV2. There are not even in the same category as AOM has stated AV2 intends for 1080P and efficiency. While ECM at its current form is 50x to 100x slower than VVC encode, and 8 - 10x slower to decode. I am not even sure if it will ever be useable.
Is there any consumer-level hardware available that supports AV1 encoding yet?
See "Encoding" column in table:
* https://en.wikipedia.org/wiki/AV1#Hardware_encoding_and_deco...
Intel Arc, AMD Radeon 7000 series, Pixel 8, GeForce 40, and a few others.
(Disregard, misread encoding as decoding)
~~And iPhones and Macs since the A15 / M3 chips~~
Intel meteor lake chips support AV1 encode/decode.
Last two generations of nvidia or so https://en.wikipedia.org/wiki/NVENC
Anyone use AV1? How good is it? What are your thoughts on AV2?
I implemented an encoding pipeline for AV1 for vids uploaded to my social news site (think reddit competitor except I'm extremely small fry). I eventually removed the code for it.
While the space savings and quality improvements are good, the encoding speed is an order of magnitude slower than using h264/vp9. In the end the user experience of causing people to wait significantly longer for an AV1 encode wasn't worth the tradeoff. To fix the user experience problem, I still had to encode a h264 version anyway, which kinda defeats the point when it comes to space savings. You still get data transfer improvements, but the break even point for when the encoding costs offset the data transfer costs were around 1000 views per min of video encoded, and as an average I'm far below that.
IMO there's a reason why YouTube only encodes AV1 for certain videos - I suspect it's based off of a view count. Past that point they trigger a AV1 encode, but it isn't worth it to do all videos, at least right now.
Worth keeping in mind I was looking at this ~2 years ago, so things may have evolved since then.
>IMO there's a reason why YouTube only encodes AV1 for certain videos - I suspect it's based off of a view count. Past that point they trigger a AV1 encode, but it isn't worth it to do all videos, at least right now.
But how can they do that without storing the original uploaded video until it hits that view count?
Do they actually store the original uploaded video somewhere, but reencode for the edge servers to save data/storage?
[dead]
Things have gotten a lot better. You were probably using the reference encoder, but there's a newer, much faster encoder: svt-av1.
AV1 is really one of those things born out of internet providers (e.g. Google, Amazon) put together so they can deliver content more efficiently with their bandwidth without needing to deal with a complicated web of royalties in addition to paying said royalties. There's plenty of people using AV1 or it's image format but don't realize it.
Also, video encoding pretty much always comes with the tradeoff of more efficient = uses more processing power
I did some testing with the 3 main AV1 encoders with gifs (avif). They’re pretty good. But not as good as jpeg xl but currently basically only Safari supports it.
See my blog: https://catskull.net/libaom-vs-svtav1-vs-rav1e-2025.html
For most “normie” use cases, I’d recommend cloudflares image transforms which are available on free tier. I actually wrote a small Jekyll plugin for my site to auto prefix images with their transform. Idk why but shipping optimized images is just one of those things that tickles me!
https://developers.cloudflare.com/images/transform-images/
Lots of people are using AV1. They just don't know it.
In my experience (not professional, encoding various files for archiving or sharing), AV1 perform quite well for low bitrate situation/streaming, and the encoder is reasonably fast (not as fast as h264 ofc, but that's decades of work on it).
But for higher quality encoding, I personally found that h265/HVEC almost always beat it, with similar encoding time.
As for AV2, I just hope that we get a good open-source encoder.
I manually turn AV1 off on my android phone. It uses more battery and won't sustain 1440p at 1.5x speed up without the odd frameskip.
Netflix streams in AV1 to devices that support it.
I use AV1, it is very efficent
Encoder are extremely slow.
SVT-AV1 is the fastest software encoder for pretty much any level of quality you would want.
https://engineering.fb.com/2023/02/21/video-engineering/av1-...
[dead]
This might be a response to H.266/VVC, which was finalized in 2020 but apparently saw limited adoption so far: https://en.wikipedia.org/wiki/Versatile_Video_Coding
Totally different goal, but I wish there was a liberatory/non/less-encumbered form for realtime video production too.
A lot of good streaming hardware does jpeg-xs, ISO/IEC 21122, for real-time encoding basically from the camera to the mix station. It's still extremely high bit-rate mostly, but very low latencies. https://en.wikipedia.org/wiki/JPEG_XS
Wow
Great, another codec that makes old hardware obsolete through lack of hardware acceleration.