AOmedia next (AV2) codec [Archive]

BlueLane

19th August 2021, 18:41

Some promising initial results. I appreciate the simplification work for hardware decoders; AV1 is rather a beast to implement in low-cost hardware.

Building off the libaom encoder makes for an enormously faster test encoder for this stage of development compared to MPEG codecs, which is very helpful for rapid iteration of experiments and testing a wide variety of content and scenarios.

Ben, what about hardware encoding of AV1? Is that also a beast?

I wonder if AV2 simplifies hardware encoding over AV1.

The use case I'm thinking of most is security cameras, like the Ring systems, as well as more commercial/industrial systems. This means real-time encoding, not the kind of optimized, curated encoding Netflix or Prime Video would take its time with.

And it also means lower framerates in many cases. A default frame rate when no motion is detected might be something like 3 fps, just there as a backup to capture events that somehow didn't trigger the motion detectors. When the motion detectors fire, then the camera would flip into something like 15 or 20 fps, still lower than standard 30 fps video or 24 fps film. The motivation is to conserve storage capacity, since nothing eats storage like video, and higher framerates aren't necessary for surveillance.

I wonder what the codec design implications are for such a use case, and if any of the newer codecs contemplate these reduced framerate scenarios. The "trickle" or standby rate of ≈3 fps is interesting because it will almost always consist of invariant video, of just frame after frame of the same thing, with perhaps slight movement of things like leaves, grass, flags, etc. due to wind. Do most codecs handle invariance well? I assume that any kind of delta encoding would deliver huge compression ratios.

And the 15-20 fps action streams are more the opposite in that there will be lots of bulk movement in the frame, with maybe only homogenous perimeters. I'm not sure what the implications are for codecs. Efficiently encoding action is probably their main gig, though they also like to leverage the invariant parts of frames.

I wonder if the reduced framerate would make most codecs less efficient, because there's less interframe duplication per unit time. Given X amount of delivery driver movement in a one-second span, 30 frames should carry less interframe differentiation than 15 or 20 frames. In the latter case, each frame should be less similar to its predecessor than in the 30 fps case, right? That seems to imply less bitrate reduction per second in the 15-20 fps case, compared to 30 fps, as a percentage. How that plays out in terms of raw bitrate figures is interesting – could 30 fps end up costing the same bitrate as 15 or 20 fps with some codecs?

nhw_pulsar

27th August 2021, 21:12

Ben, what about hardware encoding of AV1? Is that also a beast?

I wonder if AV2 simplifies hardware encoding over AV1.

The use case I'm thinking of most is security cameras, like the Ring systems, as well as more commercial/industrial systems. This means real-time encoding, not the kind of optimized, curated encoding Netflix or Prime Video would take its time with.

And it also means lower framerates in many cases. A default frame rate when no motion is detected might be something like 3 fps, just there as a backup to capture events that somehow didn't trigger the motion detectors. When the motion detectors fire, then the camera would flip into something like 15 or 20 fps, still lower than standard 30 fps video or 24 fps film. The motivation is to conserve storage capacity, since nothing eats storage like video, and higher framerates aren't necessary for surveillance.

I wonder what the codec design implications are for such a use case, and if any of the newer codecs contemplate these reduced framerate scenarios. The "trickle" or standby rate of ≈3 fps is interesting because it will almost always consist of invariant video, of just frame after frame of the same thing, with perhaps slight movement of things like leaves, grass, flags, etc. due to wind. Do most codecs handle invariance well? I assume that any kind of delta encoding would deliver huge compression ratios.

And the 15-20 fps action streams are more the opposite in that there will be lots of bulk movement in the frame, with maybe only homogenous perimeters. I'm not sure what the implications are for codecs. Efficiently encoding action is probably their main gig, though they also like to leverage the invariant parts of frames.

I wonder if the reduced framerate would make most codecs less efficient, because there's less interframe duplication per unit time. Given X amount of delivery driver movement in a one-second span, 30 frames should carry less interframe differentiation than 15 or 20 frames. In the latter case, each frame should be less similar to its predecessor than in the 30 fps case, right? That seems to imply less bitrate reduction per second in the 15-20 fps case, compared to 30 fps, as a percentage. How that plays out in terms of raw bitrate figures is interesting – could 30 fps end up costing the same bitrate as 15 or 20 fps with some codecs?

Hi,

As nobody has answered you for now, I'll try to give you an answer even if I am not an expert...

Yes for 3fps with static invariant frames (except sometimes when there are a movement or some wind), yes I think a custom encoder would be more practical, as just simple delta encoding will be certainly the most efficient in most of the cases.Does the security cameras market is waiting for the next standard of AOM/MPEG which is not their main target/market, or a special custom encoder is conceivable? Because I have made an extremely fast codec (NHW) that has competitive results on intra coding, do you think your industry could look at NHW for a special custom codec?

Concerning AV2, yes it will be more complex than AV1, but as written in the article above, 5-7% improvement over AV1 is a good start, but as has said AOM and Google teams many times, there are other experiments underway, because they said that they clearly aim with AV2 at 25-30% more compression over AV1 to be viable and to justify a (slower) codec switch.Does this objective has diminished now?

benwaggoner

2nd September 2021, 19:10

Concerning AV2, yes it will be more complex than AV1, but as written in the article above, 5-7% improvement over AV1 is a good start, but as has said AOM and Google teams many times, there are other experiments underway, because they said that they clearly aim with AV2 at 25-30% more compression over AV1 to be viable and to justify a (slower) codec switch.Does this objective has diminished now?
A 25-30% improvement is really small potatoes for a new codec generation. Historically, we've seen broad multiple-industry adaptions of new codecs when they have a potential ~100% more compression than the prior standard technology.

MPEG-2 to H.264 offered that kind of improvement, as did H.264 to HEVC, and HEVC to VVC. Codecs that offered ~20-30% improvements, like MPEG-4 Part 2, VC-1, VP3-9, and so far AV1 haven't ever gotten much momentum outside of their primary sponsor companies and their specific ecosystems.

An AV2 30% better than AV1 would still be somewhat short of VVC. It's hard to see it becoming the "default" HW decoder unless VVC's licensing goes horribly pear-shaped.

Even with HEVC's licensing challenges, it has been ubiquitous in pretty much every video-capable SoC, GPU, CPU, etcetera for years now. It's pretty dominant for paid premium content, with user-generated and non-commercial content the main place VP9 and AV1 are used. Big markets, but still a relatively moderate slice of the overall video market pie.

nhw_pulsar

2nd September 2021, 19:57

A 25-30% improvement is really small potatoes for a new codec generation. Historically, we've seen broad multiple-industry adaptions of new codecs when they have a potential ~100% more compression than the prior standard technology.

MPEG-2 to H.264 offered that kind of improvement, as did H.264 to HEVC, and HEVC to VVC. Codecs that offered ~20-30% improvements, like MPEG-4 Part 2, VC-1, VP3-9, and so far AV1 haven't ever gotten much momentum outside of their primary sponsor companies and their specific ecosystems.

An AV2 30% better than AV1 would still be somewhat short of VVC. It's hard to see it becoming the "default" HW decoder unless VVC's licensing goes horribly pear-shaped.

Even with HEVC's licensing challenges, it has been ubiquitous in pretty much every video-capable SoC, GPU, CPU, etcetera for years now. It's pretty dominant for paid premium content, with user-generated and non-commercial content the main place VP9 and AV1 are used. Big markets, but still a relatively moderate slice of the overall video market pie.

Ok, but for AV2 to have 30-50% better compression over AV1, AOM will have to invent new breakthrough technology (and different from the VVC patented new technology).So far we can read that AOM has started to look at promising machine learning and neural networks (MPEG has also started this research), but a current "problematic" with AI is that certainly encoding will be slower but especially decoding will be very slower? Does the complexity budget will explode?

So with 30-50% improvement over AV1, I think AV2 certainly needs more years of development and won't be ready in the near future?

Blue_MiSfit

2nd September 2021, 21:41

Seems near term the lower hanging fruit for compression gains will be using AI/ML to make smarter early exits and maybe some image pre-processing (or clever post-processing with side-channel data a-la LC-EVC), plus of course good content-adaptive encoding strategies.

I'm not sure how much further we can take block sub-partitioning and motion prediction etc :D

ksec

7th September 2021, 11:29

I'm not sure how much further we can take block sub-partitioning and motion prediction etc :D

That is what I have been thinking about for quite some time as well. Law of diminishing returns.

What I really want to see is ML and Post Processing / LC on top of VVC or AV1. Especially with LC VVC. Could we squeeze another 20-30% bitrate reduction on leading edge codec?

Blue_MiSfit

7th September 2021, 22:18

Gravitator

8th September 2021, 15:10

LC-EVC absolutely allows for this.

I'm not aware of any production implementation, but in my conversations with the V-Nova folks they have implemented LC-EVC on top of VVC and AV1 for testing and got great improvements.
The analog of the hardware filter for encoding and decoding is already ready: AMD FidelityFX, NVIDIA DLSS.

benwaggoner

8th September 2021, 19:37

That is what I have been thinking about for quite some time as well. Law of diminishing returns.

What I really want to see is ML and Post Processing / LC on top of VVC or AV1. Especially with LC VVC. Could we squeeze another 20-30% bitrate reduction on leading edge codec?
This is exactly the approach MPAI (https://mpai.community/)is taking, albeit on top of EVC Baseline. But the concepts and approaches they develop there should be more broadly applicable.

As for the diminishing returns of block-based encoding, people have been predicting that for decades, but we're continuing to see 50% bitrate reductions in PSNR each decade, with even bigger psychovisual gains. We can do 4K HDR at a lower ABR than for SD MPEG-2 on DVD!

Maybe we'll hit a wall where some a new fundamental approach will be needed, but probably not for a while. There's lots of block-based enhancements proposed that aren't included in VVC or AV1.

Over the next decades, I can imagine a ML-powered fusion of block based encoding and GPU/VR-style rendering with texture mapping. So object detection and extraction for things that can be synthesized more efficiently than 2D rendered.

ksec

14th September 2021, 09:24

LC-EVC absolutely allows for this.

I'm not aware of any production implementation, but in my conversations with the V-Nova folks they have implemented LC-EVC on top of VVC and AV1 for testing and got great improvements.

I really hope they release more details soon. Although this is probably not the thread to be talking about LC and VVC.

birdie

10th April 2023, 12:27

Looks like it's being quite actively worked on:

https://gitlab.com/AOMediaCodec/avm

Tommy Carrot

17th April 2023, 22:21

I wonder how much efficiency improvement were they able to achieve so far over AV1. I know the bitstream is not finalized, so the current version is not very usable in the long run, but i'd still like to try it out, so i'd appreciate if someone could share a windows build of this codec. I'm also curious about ECM (https://vcgit.hhi.fraunhofer.de/ecm/ECM).

paul97

18th April 2023, 10:49

https://gitlab.com/AOMediaCodec/avm/-/pipelines/839933609 I suggest this, though at the moment the deblocking is a bit destroyed.
aomenc.exe C:\Users\Use\Videos\cs.yuv --cpu-used=9 --threads=4 --min-qp=57 --width=1366 --height=768 --max-qp=124 -o C:\Users\Use\Videos\single.ivf -
aomdec C:\Users\Use\Videos\single.ivf -o C:\Users\Use\Videos\csao.y4m
ffmpeg.exe -i C:\Users\Use\Videos\csao.y4m C:\Users\Use\Videos\aua.png
on i3 330m I can't decode more than one frame with yuv and aomenc

Job Build (x86_64-mingw-gcc): [inspection-accounting]
just search inspect and will appear

Tommy Carrot

18th April 2023, 20:59

Thank you! I've taken (x86_64-mingw-gcc): [nasm] from the latest main branch build, and after some DLL hunting, i managed to get it work.

The encoder crashes on most of my test clips, so i could only test it on some SD samples. So far it seems to be a few % more efficient than AV1, so from a purely technical standpoint, it's still quite far behind VVC, at least in SD stuff.

hajj_3

5th May 2023, 20:25

experimental AV2 support added to avif: https://github.com/AOMediaCodec/libavif/pull/1361/commits/4ab0eade81837e6c5709fff8829316c5e273de82

birdie

6th May 2023, 14:56

experimental AV2 support added to avif: https://github.com/AOMediaCodec/libavif/pull/1361/commits/4ab0eade81837e6c5709fff8829316c5e273de82

That's weird. AVIF was finalized or so it seemed.

Now it's not? Now you can have AVIF images based on AV2 features and no existing application will be able to read them?

nevcairiel

6th May 2023, 21:13

Its no different from having a MP4 file with a new video codec. Why redefine the container if it works?

Jamaika

7th May 2023, 07:32

AV1 SIMD does not work with GCC 13.0.0
Does AV2 SIMD work with GCC 13.0.0?

Tommy Carrot

17th June 2023, 12:58

I've tested the latest build, and it's finally not crashing on higher resoulutions, so i could get a broader impression. Definitely a noticable improvement over AV1, detail retention and motion stability are both significantly better. The overall quality is pretty close to VVC, albeit much slower, but that is understandable for a work-in progress reference encoder. Interesting behaviour of the encoder is that if i dont specify keyframe intervals, the first keyframe will be encoded to a significantly higher quality, but it takes so much space that the overall quality for a given bitrate is always better if i set keyframe intervals (in my case 150).

CodecWar

7th July 2023, 09:27

Its just conducted a study comparing AV1 and AV2 video codecs : https://codecwar.com/compare/av1-vs-av2

CodecWar

7th July 2023, 12:53

Its just conducted a study comparing AV1 and AV2 video codecs : https://codecwar.com/compare/av1-vs-av2

PS

Need to log in to see the all graphs

Jamaika

10th October 2023, 17:37

How to use this for ffmpeg?
[libavm-av2 @ 0000028e412307a0] v5.0.0-76120a1
Output #0, webm, to 'output_avm.webm':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf60.15.100
Stream #0:0(und): Video: av1, yuv420p10le(tv, progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 3000 kb/s, 29.97 fps, 1k tbn (default)
Metadata:
handler_name : VideoHandler
vendor_id : [0][0][0][0]
encoder : Lavc60.30.102 libavm-av2
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
Stream #0:1(und): Audio: opus, 48000 Hz, stereo, flt, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
vendor_id : [0][0][0][0]
encoder : Lavc60.30.102 libopus
[vost#0:0/libavm-av2 @ 0000028e40f16e30] Error submitting a packet to the muxer: Invalid data found when processing input
[out#0/webm @ 0000028e40dd67d0] Error muxing a packet

hajj_3

28th November 2023, 09:23

benwaggoner

28th November 2023, 21:15

Here is a list of the remaining european VC-1 patents and their expiry dates:

EP 1,528,812 - 2024-08-11
EP 2,290,991 - 2024-08-11
EP 1,661,387 - 2024-09-02
EP 1,656,793 - 2024-09-03
EP 1,656,794 - 2024-09-03
EP 1,658,726 - 2024-09-03
EP 1,665,761 - 2024-09-03
EP 2,285,113 - 2024-09-03
EP 2,285,114 - 2024-09-03
EP 2,285,115 - 2024-09-03
EP 2,323,398 - 2024-09-03
EP 2,323,399 - 2024-09-03
EP 2,323,406 - 2024-09-03
EP 2,451,161 - 2024-09-03
EP 2,466,894 - 2024-09-03
EP 2,466,895 - 2024-09-03
EP 1,549,064 - 2024-11-08

AV2 can use these in under 12 months if needed. Most european h264 patents expire by March 2024 too for the original spec of h264 that is. All Xvid patents have expired too.
Not that VC-1 is of practical use these days, but the VC-1 reference encoder was pretty much the commercial WMV implementation, so included a lot of interesting techniques that would now be available. Its adaptive deadzone implementation had some really good implementation (and thank goodness, as its delta QP signaling had a high overhead).
It also did a lot of early HEVC-like variable interprediction block size and shape stuff. And a decent overlap transform.

I don't know how applicable any of that would be to AV2, however. It's been a long time since I lived and breathed VC-1 optimization.

hajj_3

29th December 2024, 22:42

Jamaika

30th December 2024, 08:55

Okay it's amazing. Unfortunately av1 creates video quite slowly compared to hevc and av2 even slower. Although everyone writes that the processor load is the same. However visually the avm project looks better and runs faster than ECM i.e. h267.
I don't know why the C++ additions in av2 are under <pthread.h> for gcc???
Not all the fixes work under gcc. The question is whether gcc doesn't work or the fixes have been there for half a year???
Yes av2 can be added to libavif, libwebp2 but no one has foreseen viewer.

Detele error: CONFIG_ENABLE_IBC_NAT, CONFIG_IBP_WEIGHT

ksec

31st December 2024, 16:34

AV2 talk on youtube by google engineers from August 2024: https://www.youtube.com/watch?v=bCwjTVJ3F3w

They said that AV2 compression is currently 24-25% better than AV1 for normal content and video games and 30%+ better for screen-content e.g powerpoint presentations, screen sharing etc. They said that they are focusing more on 1080p rather than 4k as most content on social media is 1080p. They said they are focusing on making the amount of die space low for hardware decoders.

Google's goal is a 40% compression improvement over AV1. Apple would be happy with 25-30%. They are aiming for a 2x increase in complexity. They are aiming to finalise AV2 in 1-2yrs. They are considering adding alpha channel support and considering adding up to 16 bit colour depth support. Presumably alpha channel and 16bit are for a future AVIF image format.

Looks like they have ( finally ) learned their lesson with AV1. Looking forward to AV2.

oibaf

5th January 2025, 11:45

Jamaika

5th January 2025, 17:16

hajj_3

6th January 2025, 00:46

I know but nobody is in a hurry here. I don't even know if there is interest in the subject. I treat it only as a curiosity. Someone can take a picture of AV2 with the provided link to libwebp2. Compare it with WEBP, WEBP2, AV1, JXL, JXS, JP2000HT and that's it. The websites don't provide information today when the h267 or av2 codecs will be implemented?

The latest H.267 roadmap (https://www.mpeg.org/wp-content/uploads/2024/12/Roadmap_after_MPEG_148.pdf) (page4) shows that it will be ratified in late 2026/early 2027. As for AV2 The 4 month old video i posted said they are planning to finalise it in 1-2yrs.

Jamaika

6th January 2025, 09:03

The latest H.267 roadmap (https://www.mpeg.org/wp-content/uploads/2024/12/Roadmap_after_MPEG_148.pdf) (page4) shows that it will be ratified in late 2026/early 2027. As for AV2 The 4 month old video i posted said they are planning to finalise it in 1-2yrs.
However something did come up.
MPEG Immersive Video v.2 2023-2035 - I understand that it will not be renewed.
https://github.com/MPEGGroup/isobmff/tags
File Format (ISOBMFF) v.9 - ... but where to download git to mpeg-5 container.
... Audio Coding for Machines 2025-2027 sounds mysterious too

ksec

11th January 2025, 12:46

AV2 talk on youtube by google engineers from August 2024: https://www.youtube.com/watch?v=bCwjTVJ3F3w

They said that AV2 compression is currently 24-25% better than AV1 for normal content and video games and 30%+ better for screen-content e.g powerpoint presentations, screen sharing etc. They said that they are focusing more on 1080p rather than 4k as most content on social media is 1080p. They said they are focusing on making the amount of die space low for hardware decoders.

Google's goal is a 40% compression improvement over AV1. Apple would be happy with 25-30%. They are aiming for a 2x increase in complexity. They are aiming to finalise AV2 in 1-2yrs. They are considering adding alpha channel support and considering adding up to 16 bit colour depth support. Presumably alpha channel and 16bit are for a future AVIF image format.

I just rewatched the video, I have high doubt on how they will achieve an extra 15% compression with next 12 months and ratified the standard in another 6.

I cant help but thank given the history of AOM constantly over promise and under deliver I am as skeptical as usual. I hope they have a free AV2 hardware decoder ready as well that is energy efficient as they originally promised with AV1.

olduser217

13th January 2025, 03:26

I just rewatched the video, I have high doubt on how they will achieve an extra 15% compression with next 12 months and ratified the standard in another 6.

I cant help but thank given the history of AOM constantly over promise and under deliver I am as skeptical as usual. I hope they have a free AV2 hardware decoder ready as well that is energy efficient as they originally promised with AV1.

Referring to the history of AV1, I won't be surprised if AV2 standard is completed beyond the initial promised date (unless AOM compromises the compression target).

The free AV2 hardware design may not be much useful for major SoC companies, as it may not suit the existing architecture of their design that includes other standards.

kurkosdr

13th January 2025, 21:17

Here is a list of the remaining european VC-1 patents and their expiry dates:

EP 1,528,812 - 2024-08-11
EP 2,290,991 - 2024-08-11
EP 1,661,387 - 2024-09-02
EP 1,656,793 - 2024-09-03
EP 1,656,794 - 2024-09-03
EP 1,658,726 - 2024-09-03
EP 1,665,761 - 2024-09-03
EP 2,285,113 - 2024-09-03
EP 2,285,114 - 2024-09-03
EP 2,285,115 - 2024-09-03
EP 2,323,398 - 2024-09-03
EP 2,323,399 - 2024-09-03
EP 2,323,406 - 2024-09-03
EP 2,451,161 - 2024-09-03
EP 2,466,894 - 2024-09-03
EP 2,466,895 - 2024-09-03
EP 1,549,064 - 2024-11-08

AV2 can use these in under 12 months if needed. Most european h264 patents expire by March 2024 too for the original spec of h264 that is. All Xvid patents have expired too.
Why would a company like Google, which distributes video from US territory (YouTube) and encoder and decoder software from US territory, care about the fact that the European patents have expired? There is the theoretical possibility of Google moving its operations completely outside the US and changing headquarters to Europe, but realistically, it's not happening.

Same for H.264, until the US patents expire too, the technologies they describe are out of reach for WebM. In fact, since WebM is meant to be royalty-free on a (reasonably) global basis, the patents for every major market have to expire, so that possibly includes Brazil.

The expiration of VC-1 patents for every country except the US and Brazil sometime this year will benefit companies that make Blu-ray players (since they'll only have to pay patent royalties for products sold in the US and Brazil for VC-1), but that's it.

kurkosdr

13th January 2025, 21:19

Its just conducted a study comparing AV1 and AV2 video codecs : https://codecwar.com/compare/av1-vs-av2
If you are still reading this thread, the website doesn't work.

benwaggoner

14th January 2025, 21:38

Referring to the history of AV1, I won't be surprised if AV2 standard is completed beyond the initial promised date (unless AOM compromises the compression target).
My sense from various stakeholders is that the standard will be done this year. I don't think they'd hold it another year to get a few more percent savings.

Among other things, the market needs seem clearer than ever, with VVC licensing not having coalesced into something straightforward yet.

benwaggoner

14th January 2025, 21:42

Why would a company like Google, which distributes video from US territory (YouTube) and encoder and decoder software from US territory, care about the fact that the European patents have expired? There is the theoretical possibility of Google moving its operations completely outside the US and changing headquarters to Europe, but realistically, it's not happening.
Google distributes video from data centers all around the world, not just the USA. Any company of that size with that pervasive a reach has a legal locus pretty much everywhere.

Same for H.264, until the US patents expire too, the technologies they describe are out of reach for WebM. In fact, since WebM is meant to be royalty-free on a (reasonably) global basis, the patents for every major market have to expire, so that possibly includes Brazil.
Except for patents held by AOM member companies, who license them for AOM use. Which is a pretty decent slice of codec IP.

kurkosdr

15th January 2025, 12:07

Google distributes video from data centers all around the world, not just the USA. Any company of that size with that pervasive a reach has a legal locus pretty much everywhere.
Yes, but they also distribute video from the US, so unless those US patents expire, they cannot use the technologies those US patents describe in AV2, because then AV2 goes out of reach for their US datacenters.

Except for patents held by AOM member companies, who license them for AOM use. Which is a pretty decent slice of codec IP.
It's patent-encumbered but royalty-free, in fact, AOM doesn't have a royalty structure, if you trigger the "defensive termination" clauses you can't pay to license the AOM patents even if you wanted to.

(when I said "the patents for every major market have to expire" above, I obviously meant the ones not held by AOM)

benwaggoner

16th January 2025, 18:09

Yes, but they also distribute video from the US, so unless those US patents expire, they cannot use the technologies those US patents describe in AV2, because then AV2 goes out of reach for their US datacenters.
At Google's scale, they absolutely could encode in different countries for distribution in specific countries in order to get around patent stuff. At least for Premium content; YouTube has quite different cost models.

It's patent-encumbered but royalty-free, in fact, AOM doesn't have a royalty structure, if you trigger the "defensive termination" clauses you can't pay to license the AOM patents even if you wanted to.
Correct. AOM provides both a list of "here's patents you can use royalty-free if you're using an AOM codec" and "here's companies that can't sue you for using an AOM codec."

Patent farms and submarine patents are the biggest risks, in my opinion, as they're not ecosystem stakeholders but simply are trying to extract as much revenue as possible irrespective any ecosystem damage.

Thank goodness for Unified Patents! They do great work invalidating low-quality patents and making patent farms have to work harder and face more risk in ecosystem disrupting activites.

paul97

16th March 2025, 17:42

please anyone can build avm merge request cdef enhancement or master for windows ten sse4? thanks in advance

Jamaika

17th March 2025, 08:39

Not everyone will be happy. For those willing, AVM codec AVX.
https://www.sendspace.com/file/xc74zd

benwaggoner

17th March 2025, 18:45

please anyone can build avm merge request cdef enhancement or master for windows ten sse4? thanks in advance
What are you trying to do on such ancient hardware? Given the complexity of the in-development AV2 encoder today, I doubt you'd be able to get much encoded before the next update ;).

ksec

22nd March 2025, 15:54

My sense from various stakeholders is that the standard will be done this year. I don't think they'd hold it another year to get a few more percent savings.

Among other things, the market needs seem clearer than ever, with VVC licensing not having coalesced into something straightforward yet.

Then it is bad. And AOM as usual. I guess I am still too naive and too optimistic even at my age.

If they want it done this year they should at least release a beta version or 0.8 draft version. I think many have said this but I guess it is worth repeating. AOM is anything but Open.

Z2697

23rd March 2025, 03:15

AOM is anything but Open.

What makes you think like this?

GeoffreyA

23rd March 2025, 17:46

What makes you think like this?

I'm not sure, but doesn't Google have mostly tight fingers over contributions to be codebase?

modus-ms325c

24th March 2025, 16:31

I'm not sure, but doesn't Google have mostly tight fingers over contributions to be codebase?
ironically enough (and technically keeping with the "tight fingers" subject), this is kinda how cuavas handles outsiders' contributions to the MAME codebase as of late.
just ask the "bannister forums" folks.

Tommy Carrot

26th April 2025, 10:21

Working AV2 windows build (MSVC):
https://www.mediafire.com/file/3ytz9ql4zwlfr4m/av2_250425.7z/file

If someone wants to try encoding with it, i'd recommend to set --enable-uneven-4way-partitions to 0. I had crashes with it on certain resolutions, unless i disable it.

GeoffreyA

26th April 2025, 14:49

Z2697

26th April 2025, 16:04

I think they (AOM and its predecessor) have changed the direction of the official library: at least from libvpx to libaom, they are both reference implementation and "production ready", at least they tried to. Now the AVM is not production ready at all, just like reference implementations in the MPEG side.

GeoffreyA

26th April 2025, 18:47

BlueSwordM

27th April 2025, 20:45

Jamaika

27th April 2025, 21:42

The main trick with CWG, aka proposals, is that they have to be rock solid to find themselves into production.
Their definition of rock-solid depends on a lot of members: hardware teams, software teams and worst of all, PSNR/SSIM scores.
Some of us have had to do a lot of work convincing peeps that a feature that increases perceptual quality and SSIMU2/butteraugli-jxl/XPSNR scores at the cost of non perceptual blur metrics, PSNR/SSIM.
2 features were added with the behaviors cited above and yet, some people complained :P
They did manage to go through, but it was hard.

I created something but not everything works for me under gcc.
I deleted CONFIG_ENABLE_IBC_NAT, CONFIG_IBP_WEIGHT.
Frames-I for AV2 work for me under libwebp2. I'll add plus for AV2 for large size 5212x3468 support.
av2enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim image_jpeg.wp2 -d output.av2
tune butteraugli workes with latest jpegxl. Delete default BT709:
/*if (img->mc != 0 && img->mc != AOM_CICP_MC_BT_709 &&
img->mc != AOM_CICP_MC_BT_601 && img->mc != AOM_CICP_MC_BT_470_B_G) {
ERROR(
"Only BT.709 and BT.601 matrix coefficients supported in "
"tune=butteraugli mode. Identity matrix is treated as BT.601.");
}*/

av1enc_avx.exe -q 100 -444 -size 280x420 -effort 7 -threads 4 -tune butteraugli image_jpeg.wp2 -d output.av1

I wasn't able to create a movie.
https://gitlab.com/AOMediaCodec/avm/-/commit/0ee2f9e68420aef0d69aa91cd975decc71064bcd
ffmpeg_avx2.exe -i "video.mp4" -f rawvideo -vf scale=1920:1080: in_range=limited: out_range=limited -frames:v 500 -pix_fmt yuv420p - | aomenc.exe --verbose --limit=500 --input-bit-depth=8 --i420 --width=1920 --height=1080 --ivf --good --passes=1 --pass=1 --bit-depth=8 --fps=30000/1001 --threads=20 --cpu-used=9 --end-usage=cq --qp=0 -o avm_yuv420p10le.ivf -

Assertion failed: is_inter_compound_mode(mode), file c:\gcc1150\x86_64-w64-mingw32\include\av1\common\blockd.h, line 178

https://www.sendspace.com/file/gh11if

benwaggoner

2nd May 2025, 02:00

The main trick with CWG, aka proposals, is that they have to be rock solid to find themselves into production.

Their definition of rock-solid depends on a lot of members: hardware teams, software teams and worst of all, PSNR/SSIM scores.

Some of us have had to do a lot of work convincing peeps that a feature that increases perceptual quality and SSIMU2/butteraugli-jxl/XPSNR scores at the cost of non perceptual blur metrics, PSNR/SSIM.

2 features were added with the behaviors cited above and yet, some people complained :P

They did manage to go through, but it was hard.
Sir, you did the work of Heroes!

People treat PSNR like some sort of fundamental definition of distortion rather than the decades-old "eh, easy to calculate and better than the other obvious alternatives" metric it truly is. And the square root of squares gets you a free absolute value conversion.

Lots of folks with a computer science background but without a neuropsychology or vision science background can assume that PSNR is what's before psychovisual optimization. But it's ALL psychovisual optimizations. It's just some of them are so old we don't really think about how they came to be.

sRGB/Rec. 709 is a perceptual optimization that makes 8-bit encoding work well within the range of what good CRTs used to be capable of reproducing.

Gamma is a psychovisaul optimization based on a first-order approximation of the human visual and CRT EOTF, easily implemented in simple analog circuitry. PQ is the second order approximation (but assumes a specific fixed ambient light). The non-psychovisual implementation would be linear light values.

Quant/Lambda tables are psychovisual optimizations based on our more accurate perception of horizontal and vertical details versus diagonal. And historically the PAL and NTSC versions embedded the different default sample aspect ratios (720x480 versus 720x576). The non-psychovisual implementation would be a flat quantizer.

Frequency transforms like DCT and iDCT themselves are perceptual optimizations about how our eyes and brains detect edges more than absolute brightness and color spatially. The non-psychovisual implementation would probably be pixel-based. And square pixels themselves are more of a computational friendly approach. Why not triangles or hexagons?

paul97

3rd August 2025, 05:36

Have you got an AVM build for sse4 Windows 10 65 bit as they fixed msvc build yesterday? Thank You. Do it needs to compile wsl or bash.

Jamaika

4th August 2025, 08:15

https://www.sendspace.com/file/azxpwg

mlkj

15th September 2025, 20:37

AOMedia says they're planning a release of AV2 by end of year.
Not clear if that means freezing and ratifying the spec, officially branding AVM as AV2, or if it's purely symbolic to mark the anniversary.

https://aomedia.org/press%20releases/AOMedia-Announces-Year-End-Launch-of-Next-Generation-Video-Codec-AV2-on-10th-Anniversary/

birdie

16th September 2025, 00:07

The Alliance for Open Media (AOMedia), a global collaboration of innovators working together to define and deploy open standards that power the next generation of media experiences, today announced the upcoming launch of the next evolution in open video coding: AV2. Set for a year-end release, AV2 is not only an upgrade to the widely adopted AV1 but also a foundational piece of AOMedia’s future tech stack.

AV2, a generation leap in open video coding and the answer to the world’s growing streaming demands, delivers significantly better compression performance than AV1. AV2 provides enhanced support for AR/VR applications, split-screen delivery of multiple programs, improved handling of screen content, and an ability to operate over a wider visual quality range. AV2 marks a milestone on the path to an open, innovative future of media experiences.

To me it sounds like the spec will be ratified by the end of 2025.

Jamaika

17th September 2025, 13:18

To me it sounds like the spec will be ratified by the end of 2025.
I gave in. I deleted the old version of AVM 10.0.1 6b2b423, which was working. The new version won't even start in tests. It's still a long way off.
https://www.sendspace.com/file/302x5f

hajj_3

8th October 2025, 21:46

There will be a live webinar/presentation about AV2 on Monday 20th October. Presentation by Netflix, Google and Meta: https://aomedia.org/events/live-session-the-future-of-innovation-is-open/

birdie

11th October 2025, 08:15

hajj_3

11th October 2025, 10:25

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

birdie

11th October 2025, 11:40

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

AV2 will be competing with the ECM codec (https://forum.doom9.org/showthread.php?t=185662) that will also be quite a lot better than VVC albeit both will be equally dead in terms of real life applications.

ksec

11th October 2025, 11:50

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.

We need more data and considering AOM have over stated their gain and understated VVC in the past.

I am wondering if those 29-33% is compared to which version of AV1 encoder. Theoretically they could have compared to libaom 1.0 and that statement would still be true.

I am just really hoping they get everything right this time around. They said they looked into Decoder complexity, we need to know actual numbers. Fixing AVIF the format, and hopefully Av2 image format as well.

foxyshadis

11th October 2025, 19:42

I gave in. I deleted the old version of AVM 10.0.1 6b2b423, which was working. The new version won't even start in tests. It's still a long way off.
https://www.sendspace.com/file/302x5f

Status of the test encoder has nothing to do with status of the spec.

Fixing AVIF the format, and hopefully Av2 image format as well.

What's wrong with the AVIF (or HEIF) format? It's complex, but it's incredibly capable of far more complex things than storing a basic pic, and ways to exploit that capability have started becoming available this year in libheif and libavif. Meanwhile, if you do just want to store a basic picture, you don't have to care about any of that complexity and it just works, even the structure of the simplified file format is quite basic and straightforward.

For me, one of the most powerful is being able to save layers with a combination of lossy graphics and lossless text/screen content, and it just works.

Jamaika

12th October 2025, 21:08

Status of the test encoder has nothing to do with status of the spec.

What's wrong with the AVIF (or HEIF) format? It's complex, but it's incredibly capable of far more complex things than storing a basic pic, and ways to exploit that capability have started becoming available this year in libheif and libavif. Meanwhile, if you do just want to store a basic picture, you don't have to care about any of that complexity and it just works, even the structure of the simplified file format is quite basic and straightforward.

For me, one of the most powerful is being able to save layers with a combination of lossy graphics and lossless text/screen content, and it just works.
If it works like that, I'll read how it's supposed to work. 20250804
Converting a simple photo without CONFIG_ENABLE_IBC_NAT. This converter works.
https://www.sendspace.com/file/f2ddp2
Converting a simple photo with CONFIG_ENABLE_IBC_NAT. This converter doesn't work.
https://www.sendspace.com/file/hvxny9
So how do I disable the outside, inside function? What is it for? Where can I find it in help?

olduser217

13th October 2025, 03:40

A massive video detailing AV2:

https://www.youtube.com/watch?v=Se8E_SUlU3w

And info from it:

https://videocardz.com/newz/av2-video-codec-delivers-30-lower-bitrate-than-av1-final-spec-due-in-late-2025

https://i.ibb.co/s9LvP6m5/av2.webp

Talked to someone from AOM 2 years ago, they dropped the idea of adding AI module to the base profile, as the cost is too high (the chip area size) while the gain is relatively low.

kurkosdr

14th October 2025, 17:17

AV2 will be competing with the ECM codec (https://forum.doom9.org/showthread.php?t=185662) that will also be quite a lot better than VVC albeit both will be equally dead in terms of real life applications.
What does "both" refer to? AV2 and ECM? AV2 has guaranteed adoption from YouTube at the very least. Google contributed money to develop AV2 (as an AOM member), and they didn't contribute that money to not use it.

Also, Google can afford to support multiple formats since they aren't a broadcaster that has to "simulcast", they already encode 4K HDR streams three times just for the 2160p resolution (VP9 SDR, VP9 HDR, AV1 HDR) and serve you one of the three depending on what your 4K-capable device supports. They can add 1 more encode for AV2 HDR. They make dedicated encoding hardware (https://arstechnica.com/gadgets/2021/04/youtube-is-now-building-its-own-video-transcoding-chips/) to handle encoding, and it will save them more and more bandwidth as more and more devices ship with AV2 hardware decoding.

My point is, lots of people in the industry care about AV2 because their devices will have to support it eventually.

birdie

15th October 2025, 07:37

What does "both" refer to? AV2 and ECM? AV2 has guaranteed adoption from YouTube at the very least. Google contributed money to develop AV2 (as an AOM member), and they didn't contribute that money to not use it.

Also, Google can afford to support multiple formats since they aren't a broadcaster that has to "simulcast", they already encode 4K HDR streams three times just for the 2160p resolution (VP9 SDR, VP9 HDR, AV1 HDR) and serve you one of the three depending on what your 4K-capable device supports. They can add 1 more encode for AV2 HDR. They make dedicated encoding hardware (https://arstechnica.com/gadgets/2021/04/youtube-is-now-building-its-own-video-transcoding-chips/) to handle encoding, and it will save them more and more bandwidth as more and more devices ship with AV2 hardware decoding.

My point is, lots of people in the industry care about AV2 because their devices will have to support it eventually.

I meant VVC and ECM.

AV2 will be heavily pushed by Google, so circa 2030 we'll see a lot of HW implementations.

hajj_3

21st October 2025, 09:33

AVIF 2.0 is coming: https://aomedia.org/blog%20posts/AVIF-at-Five-Powering-a-Faster-Sharper-Web-Experience/

hajj_3

6th November 2025, 21:35

soresu

7th November 2025, 09:39

Talked to someone from AOM 2 years ago, they dropped the idea of adding AI module to the base profile, as the cost is too high (the chip area size) while the gain is relatively low.

Given the emphasis on AI/ML inference hw in modern SoCs you would think that the silicon is already there just waiting to be tapped, like with that end to end ML based Deep Codec or whatever it's called.

soresu

7th November 2025, 09:41

Here is the AV2 presentation by the alliance for open media from 20th october: https://www.youtube.com/watch?v=RUMwMe_2Dqo&t=267s

They said that AV2 has 30-32% better compression than AV1 at 1080p and 38% better at UHD.

Better than I expected I guess.

The question is at what enc/dec computational cost?

soresu

7th November 2025, 09:53

AV2 has guaranteed adoption from YouTube at the very least.

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.

Likewise decoding hw for AV1 should be pretty widespread across the consumer ecosystem at this point and the highly efficient libdav1d exists for the rest.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.

kurkosdr

8th November 2025, 00:55

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.

Likewise decoding hw for AV1 should be pretty widespread across the consumer ecosystem at this point and the highly efficient libdav1d exists for the rest.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.
It will be used for the 2160p resolution for sure, since 2160p is seriously bloating Google's bandwidth costs.

ksec

9th November 2025, 14:26

Here is the AV2 presentation by the alliance for open media from 20th october: https://www.youtube.com/watch?v=RUMwMe_2Dqo&t=267s

They said that AV2 has 30-32% better compression than AV1 at 1080p and 38% better at UHD.

This is finally some glimpse of hope. Lots of signs they learned from their mistakes in AV1. Assuming they actually deliver it. Still no words on computational differences.

Rumbah

9th November 2025, 19:58

They said that the decode complexity should not be more than twice of that of AV1.

oibaf

10th November 2025, 09:59

This is finally some glimpse of hope. Lots of signs they learned from their mistakes in AV1.

What do you mean exactly?
Which mistakes are you referring to, and why do you have hope now?

ksec

10th November 2025, 12:09

What do you mean exactly?
Which mistakes are you referring to, and why do you have hope now?

Roll out schedule, Hardware Design, Complexity, Features and Profile, AVIF and Still image, Conformance and Testing Kit. Lot of other small things from JVET that people take for granted.

benwaggoner

10th November 2025, 19:55

I'm surprised they didn't compare it to VVC as a 29-33% compression improvement should be better than the heavily patented VVC.
I don't know that they consider VVC enough of a competitor that people will be comparing AV2 to it.

If people weren't adopting VVC over AV1, they definitely won't over AV2.

benwaggoner

10th November 2025, 20:04

I wouldn't necessarily take that as a given.

We are 7 years into AV1 now, with supposedly in house designed transcoding hardware levied for everything on Youtube now, and yet still many videos are not first transcoded to AV1.
H.264 is the universal codec, so it makes sense they'd prioritize that over a codec that only a portion of their customer devices can decode. AV1 is also a lot more complex to get to its big compression efficiency advantages.

GIven AV2 will only increase the computational complexity further I would expect it to take quite some time before we see it brought to bear for anything but the most bandwidth intensive videos.
Well, yeah. It generally takes 3-4 years from a video standard being published before there's a significant installed base of players to even do pilot projects with. HEVC was an exception because it enabled 4K and HDR which weren't viable on existing decoders, and were only needed in new devices with 4K and HDR panels anyway.

So even if it is a decade between starting to create a codec an being able to use it broadly, we'll still want a better codec a decade from now. They're long-term investments with eventually huge payoffs.

oibaf

15th November 2025, 19:36

This video looks it was not posted earlier: AV2 Common Test Condition Latest Test Result Update, presented by Ryan Lei, Meta (https://www.youtube.com/watch?v=f0ivgL8vu9w).

benwaggoner

18th November 2025, 18:00

This video looks it was not posted earlier: AV2 Common Test Condition Latest Test Result Update, presented by Ryan Lei, Meta (https://www.youtube.com/watch?v=f0ivgL8vu9w).
Reasonably promising at this point. The v10 results are just hitting the 30% PSNR improvement threshold. v11 are behind those (presumably tuning is still required), but I imagine will catch up at the minimum.

If VVC had gotten "normal" MPEG codec adoption, these numbers wouldn't be enough to get the industry to switch to AV2. But VVC simply hasn't, so it's really HEVC and AV1 that are AV2's competitors in practice.

Note that these benchmarks are all "codec development comparison" tests. So fixed GOP, fixed QP, and really only normative features being used with barely any psychovisual or other scenario-specific tuning.

For actual practical use, the best HEVC and AV1 encoders would handily beat these early AV2 encoder implementations, both in quality @ bitrate and especially quality @ perf. All going well, we'd see some viable encoder implementations and some software decoders in 2017, with hardware decoders in 2028+ products.

Which requires patience, but isn't bad news at all. Each new, more advanced generation, if/when refined psychovisual optimizations are done, often get subjective compression efficiency gains substantially better than what PSNR would predict. I I'd expect our best 2035 AV2 encoders are able to deliver the same quality at half or less the bitrate of today's best AV1 encoders.

All AV2 decoders should be delivered with high quality AFGS1 implementations as well, which means savings for grainy/noisy content should be substantially better than that. We've really not seen significant AV1 FGS use in the wild yet due to a variety of decoder issues, and AFGS1, although the same at the lowest level, is quite a bit better in practice. Most importantly, the grain gets rendered at display resolution, not content resolution. That means grain and thus a lot of perceptual detail will be constant detail irrespective of the encoded stream's resolution. That will be particularly useful for adaptive streaming, as there will be much less visual discontinuity when switching between bitrates/resolutions than there is with 2025 adaptive bitrate implementations.

I expect we'll eventually see some pretty darn good 2160p HDR 24p encodes in the 2-4 Mbps average bitrate range. AFGS1 means that we'll see the biggest savings in the content that need the highest bitrates today.

oibaf

18th November 2025, 18:34

... barely any psychovisual or other scenario-specific tuning...

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

ksec

22nd November 2025, 13:03

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

Which is why I said the comparison of AV2 against its anchor point is at least 3-5 years behind. AV1 has had many improvement since, making some of those improvement BDRate not realistic. But I am optimistic this time around. No more flamboyant promise like they did with AV1 and everything seems much more practical .

oibaf

26th November 2025, 09:36

Having had a look at their plan for the next milestone (v13 (https://gitlab.com/AOMediaCodec/avm/-/milestones/17#tab-issues)), I found this issue interesting: Import changes from libaom (https://gitlab.com/AOMediaCodec/avm/-/issues/570): current AV2 is indeed still missing many thousands commits merged in 5+ years after the fork from aom (AV1).

Since then, many tunings were indeed merged in aom (https://aomedia.googlesource.com/aom/+/refs/heads/main/CHANGELOG) (it would be interesting to quantify the overall improvements with all these).

And it would be equally interesting to check AV2 again after merging them into it (likely a massive change, doable by someone with knowledge of both codebases, I suppose, even if a subset can be applied by a script like explained in the issue).

They just closed it:
"There is no plan to take action on this. So, closing as Won't do." :confused:
https://gitlab.com/AOMediaCodec/avm/-/issues/570

Maybe, someone else may be interested in taking it.

Z2697

26th November 2025, 12:31

I think the purpose of AVM is "for research only", indicated by the word Model in its name (just like JM, HM and VTM I suppose).
So while libaom benefits from various tunings because it's trying to be both research and "production ready", AVM is probably not going to need those.

oibaf

21st December 2025, 13:55

AV2 is coming, Sisvel is prepared (https://www.sisvel.com/insights/av2-is-coming-sisvel-is-prepared/)

soresu

23rd December 2025, 16:44

AV2 is coming, Sisvel is prepared (https://www.sisvel.com/insights/av2-is-coming-sisvel-is-prepared/)

It reads more like a "we have been paying attention - but in reality we have no idea what patents we manage are potentially infringed by AV2".

It's even more like a "I don't think anything we currently know about is covered by this, or not enough to make it worth the cost of a court case, so please come and share your patents so we can all make nuisance lawsuits together!"

hajj_3

23rd December 2025, 17:35

It reads more like a "we have been paying attention - but in reality we have no idea what patents we manage are potentially infringed by AV2".

It's even more like a "I don't think anything we currently know about is covered by this, or not enough to make it worth the cost of a court case, so please come and share your patents so we can all make nuisance lawsuits together!"

I doubt it. They probably know of some patents that a violated but want to stay quiet instead of announce them now so that the AOM can't remove those tools from the final version so they can extract money out of companies.

Kurt.noise

25th December 2025, 10:04

Is there any public AV2 decoders yet somewhere, except the AVM one ?

birdie

28th December 2025, 12:06

Is there any public AV2 decoders yet somewhere, except the AVM one ?

The spec has not been finalized yet. Expect third-party encoder/decoders at the end of 2026 at the earliest.

oibaf

31st December 2025, 16:22

It looks like they added a new milestone: https://gitlab.com/AOMediaCodec/avm/-/milestones/18

hajj_3

1st January 2026, 00:42

It looks like they added a new milestone: https://gitlab.com/AOMediaCodec/avm/-/milestones/18

I suspect that v13.0.0 will become the ratified version of AV2, that was released on december 19th and the reason why they haven't announced it is that they are probably doing benchmarks to include in their blog post announcement.

soresu

1st January 2026, 03:42

I suspect that v13.0.0 will become the ratified version of AV2, that was released on december 19th and the reason why they haven't announced it is that they are probably doing benchmarks to include in their blog post announcement.

A bit odd to start work on v14 so early then if they are finished with the research work on AV2.

IMHO someone(s) got an itchy trigger finger and made promises the AOM couldn't realistically keep given the state the project was in at the time.

Their press releases basically stated that they were releasing the actual codec by the end of 2025 - when in reality the reference encoder is not even into beta yet and the spec is nowhere to be seen.

For all the mess MPEG has allowed to happen, AOM could still learn some lessons from their regular meetings that leave little doubt as to what is going on.

modus-ms325c

2nd January 2026, 17:32

IMHO someone(s) got an itchy trigger finger and made promises the AOM couldn't realistically keep given the state the project was in at the time.

Their press releases basically stated that they were releasing the actual codec by the end of 2025 - when in reality the reference encoder is not even into beta yet and the spec is nowhere to be seen.gaslighting. this is what it's called, as a catch-all term for "unintentional lies" or just straight-up deceit by anyone unfortunate enough to even learn what that word even means.

For all the mess MPEG has allowed to happen, AOM could still learn some lessons from their regular meetings that leave little doubt as to what is going on.ok, how about instead of doing, well, that, let alone any kind of self-inspection, or god forbid, self-introspection on what went wrong with trying to promote their oh-so-finished AV2 masterpiece(TM) before they had a chance to pull this crap instead of after the fact, they just so happened to talk down to anyone about how shit VVC licensing really is (https://forum.doom9.org/showthread.php?p=2026447#post2026447).

soresu

2nd January 2026, 17:42

ok, how about instead of doing, well, that, let alone any kind of self-inspection, or god forbid, self-introspection on what went wrong with trying to promote their oh-so-finished AV2 masterpiece(TM), they just so happened to talk down to anyone about how shit VVC licensing really is (https://forum.doom9.org/showthread.php?p=2026447#post2026447).

"For all the mess MPEG has allowed to happen" was I thought a pretty obvios reference to the licensing business that has kneecapped their standards.

I was talking about using recorded meetings so that any interested parties know what is going on at regular intervals during the year instead of having to go through a whole song and dance of contacting people and what not.

MPEG may have screwed the pooch over the licensing, but the meetings part at least works.

modus-ms325c

2nd January 2026, 18:56

in all fairness, MPEG meetings didn't exclusively consist of people deciding the fate of (or even the strategy of promoting and/or deploying) certain codecs behind everyone's backs. no "secret circle" bullshit between participaing corporate members, even.

Emulgator

2nd January 2026, 23:44

Not tending to any side, just adding:
A few years back I had remembered a remarkable shoutout from 1988 founder Chiariglione himself being very unhappy with the situation, can not find it back just now.
Interesting read (for me too):
Before Chiariglione left (2019)
https://leonardo.chiariglione.org/5-1-the-mpeg-organisation/
after his leave in 2020
https://leonardo.chiariglione.org/

ksec

3rd January 2026, 21:39

A bit odd to start work on v14 so early then if they are finished with the research work on AV2.

IMHO someone(s) got an itchy trigger finger and made promises the AOM couldn't realistically keep given the state the project was in at the time.

Their press releases basically stated that they were releasing the actual codec by the end of 2025 - when in reality the reference encoder is not even into beta yet and the spec is nowhere to be seen.

For all the mess MPEG has allowed to happen, AOM could still learn some lessons from their regular meetings that leave little doubt as to what is going on.

I am not surprised, it was actually the same when they released AV1.0.

I was planning to say it when they released AV2, but I may as well say it now, AV2 was supposed to be released in 2020 on their original roadmap and AV3 in 2022.

We are now 2026.....

hajj_3

3rd January 2026, 23:13

I am not surprised, it was actually the same when they released AV1.0.

I was planning to say it when they released AV2, but I may as well say it now, AV2 was supposed to be released in 2020 on their original roadmap and AV3 in 2022.

We are now 2026.....

I think that is because OEMS said that they didn't want that as they would have to use lots of die space to keep supporting lots of new codecs. I'm glad they didn't rush out a successor. Most phones don't even have an AV1 decoder so convincing them to have lots of new decoders would have been impossible.

soresu

5th January 2026, 02:43

Z2697

5th January 2026, 06:09

Well you know, Apple is one of the funding members of AOMedia actually.

benwaggoner

5th January 2026, 18:17

I doubt it. They probably know of some patents that a violated but want to stay quiet instead of announce them now so that the AOM can't remove those tools from the final version so they can extract money out of companies.
Both are likely scenarios in my personal opinion.

There's also a huge difference between "such a good essential patent that it will hold up under appeal" and "a bunch of patents that it is easier to pay off the holder for than any one organization to spend years and millions taking to court." Patent trolls rely on the latter a lot.

soresu

5th January 2026, 18:19

Well you know, Apple is one of the funding members of AOMedia actually.

Which doesn't mean that much in the grand scheme of things.

What really matters is development + patent contributions and adoption rate.

They joined 2 months before AV1 released (ie no dev contribution), and as we know their hw asic adoption rate was pretty terrible.

Best case scenario their patents helped AV2 development and bolstered the defense of AV1 vs Sisvel - but I have no idea about that on either count.

If anyone has any information about Apple employees contributing to AVM work directly then by all means chime in, I'm open to being convinced.

We'll see how fast their adoption rate is for AV2 given they have no excuse for being late to the party this time around.

ksec

5th January 2026, 18:31

Well you know, Apple is one of the funding members of AOMedia actually.

Apple's name wasn't or its logo even added until very late in the cycle. IRRC about a year and a half later.

And their logo wasn't even official.

benwaggoner

5th January 2026, 18:31

I think that is because OEMS said that they didn't want that as they would have to use lots of die space to keep supporting lots of new codecs. I'm glad they didn't rush out a successor. Most phones don't even have an AV1 decoder so convincing them to have lots of new decoders would have been impossible.
Yeah. The rule of thumb is that a new codec has to offer the potential of reducing bitrate in around half for the same quality to be adopted, or unlock important new content classes. Releasing them more frequently than those sorts of gains can be delivered just splits the installed base. And die space is becoming a bigger concern now that we can't expect Moore's Law to drop the price of a given decoder block in half every couple of years. New codecs have to be carefully designed to offer the maximum compression efficiency gains in the lowest mm^2 delta possible. AV1 didn't do well on that metric, as it inherited lots of x86 software decode design. A VVC decoder is actually a fair bit smaller than a AV1 decoder while offering superior compression efficiency. Hardware decoder complexity seems to have been a much bigger priority in AV2 development.

MPEG-2 was maybe 20% more efficient than MPEG-1, but added support for interlaced. MPEG-4 part 2 was potentially maybe 20-30% more efficient than MPEG-2, which wasn't enough to overcome its own patent licensing challenges. Thus H.264, which brought really innovative new technology to hit (and eventually exceed) 50% reduction compared to MPEG-2, and a chastened set of IP holders who signed on to the MPEG-LA terms. HEVC brought 4K and HDR and about 50% bitrate reduction, enabling it to overcome its licensing ambiguity (and leveraging good will and hopeful expectations from H.264). VVC does over 50% bitrate reductions, but no new content types of mass market interest (and sustains the bad experiences and dashed expectations from HEVC).

So far AV1 hasn't been enough better or close enough to universal than H.264 to replace it, although it has seen additive use, particularly for SD content, from user-generated content (which doesn't need hardware DRM or hardware decoder), and more recently from premium streaming companies (as the critical mass of devices with HW DRM and decoding has crossed ROI thresholds).

My personal guess on the day when a streaming provider could viably stop having a H.264 fallback available is likely to hit sometime in the early 2030's. Younger readers may not remember, but some MPEG-4 part 2 and VC-1 fallbacks weren't finally deprecated until around ten years ago, after the last pre-H.264 devices dropped out of significant use.

benwaggoner

5th January 2026, 18:40

Best case scenario their patents helped AV2 development and bolstered the defense of AV1 vs Sisvel - but I have no idea about that on either count.
Having essential patents for one aspect of a codec isn't much defense against a non-practicing entity having an essential patent on another. When two companies working in good faith have a bunch of patents, they can cross-license. But a NPE is only it in for the money, and so will act in parasitic revenue-maximize way with little regard for the health of the overall market.

We'll see how fast their adoption rate is for AV2 given they have no excuse for being late to the party this time around.
I don't know if "excuse" is fair. Putting a decode block on a SoC still causes incremental heat and power draw even when it is unused. Not a huge deal in a desktop GPU, but a very real concern in a modern phone trying to optimize for every percent of battery life and peak compute performance. And of course, more area directly increases cost of a SoC, as it reduces per-wafer yield. Apple likely had a target process density and market penetration where AV1 decode had a sufficiently non-negative ROI, and introduced it then. If AV2 decode adds significant incremental complexity on top of AV1, we can expect different companies to time introduction based on similar logic.

All going well, we could start seeing AV2 HW decoders in mass-market products in the latter part of 2028, and maybe a few lower volume things earlier than that. There are a fair number of long poles that don't start moving until the bitstream spec is fully locked down. AV2 is close enough that I am sure initial design work has begun. But real commitments for the 2026 simulations for 2027 test SoCs for 2028 products won't happen before the spec is final.

soresu

5th January 2026, 22:23

I don't know if "excuse" is fair. Putting a decode block on a SoC still causes incremental heat and power draw even when it is unused. Not a huge deal in a desktop GPU, but a very real concern in a modern phone trying to optimize for every percent of battery life and peak compute performance. And of course, more area directly increases cost of a SoC, as it reduces per-wafer yield. Apple likely had a target process density and market penetration where AV1 decode had a sufficiently non-negative ROI, and introduced it then. If AV2 decode adds significant incremental complexity on top of AV1, we can expect different companies to time introduction based on similar logic.

My wording of excuse was based on the other smartphone and streaming SoC players besides QC and Apple which had AV1 decoders in their SoCs years earlier.

That's early 2020 for Amlogic, April 2020 for Mediatek, and January 2021 for Samsung.

Even Rockchip's long delayed RK3588 came out in late 2021/early 2022 - at least 6-9 months before the first QC SD 8 Gen2 in November 2022 and a good year and a half before Apple's first SoC in September 2023.

TV SoCs are known for lagging more than a little behind the state of the art, but they still had AV1 support significantly before these flagship mobile SoC/device brands.

I know all of the many excuses both QC and Apple have used when this subject comes up, but frankly based on the amount of money they throw about on state of the art process nodes and silicon design I simply don't buy any of it for a second.

It would be far easier to take such explanations as honest truth rather than corporate dissembling if they didn't have potential skin in the MPEG/proprietary codec game, the details of which have been addressed on this very forum multiple times.

When you add in the time to ASIC decoder implementation after the HEVC 02/12 standard for both QC and Apple it does display a pretty obvious proprietary engineering bias by comparison:

1.5 yrs for SD 805, and 3.5 yrs for Apple A9.

vs AV1 timeframe:

4.5 yrs for SD 8 Gen2 (SoC only - most devices usally lag months behind), and 5.5 yrs for Apple A17.

ksec

10th January 2026, 08:26

I know all of the many excuses both QC and Apple have used when this subject comes up, but frankly based on the amount of money they throw about on state of the art process nodes and silicon design I simply don't buy any of it for a second.

It is not just about process. All TV SoC including many other electronics devices and even Intel iGPU can do hardware AV1 decode before Mobile SoC because they have a much higher power budget to work with and are on lower end process where iteration is far cheaper. These hardware IP are far less energy usage sensitive. Anywhere from 2-4W. Mobile SoC not only have to do it in Sub 1W. they do it in sub 0.5W with later iteration to 0.3W. Which is both AVC and HEVC.

And an extreme power efficient design for new codec just doesn't come in day 1. Let alone on new node. If you have an ultra efficient AV2 hardware decoder IP ready today it will still be 2027 iPhone at the earliest. But given IP design and integration takes time even an 2028 release is too optimistic. And that is assuming the spec is done and you have testing kit ready along with other conformance requirement sets. Which we have zero today. In reality unless they are well prepared, which in typical AOM fashion they are not, 2030 is when you should expect hardware decoder on Mobile Phone for AV2.

That is why recent MPEG meetings has ( finally ) talked about Codec Time to Market. May be stop releasing spec without all the realistic requirements around it.

And all of that is ignoring delays in management decisions, patients issues, whether we should put resources into designing the IP in the first place, video decoder block updating schedule. A new Soc doesn't;t always mean a new decoder block. All the other nuance which people overlook and take it for granted. Shipping Hardware isn't magic, most people, especially software developers got so used to Internet doing the delivery and logistics and shipping software correcting with a press of a button on SaaS, or ship a new version to App Store to approve in days and forget the whole Hardware shipping takes months and cant easily be updated. There are a lot of testing involved.

And lastly, 2026 marks the year I have been saying this for 10 years. Every single day passed is another day favouring good old H.264 AVC High Profile. Storage Cost isn't falling as it used to, in fact in recent few months it is increasing, and the trend will be continue the increase till 2028 / 2029. Storing video in another format has cost depending on their business models. i.e Youtube, Facebook and Netflix as well as Broadcasting are all very different. But thanks to AI Networking cost is projected to keep falling. It is actually easier to broadcast 20%+higher bitrate AVC on the internet then switching to another codec. Since AVC is a baseline requirement and not looking to go away any time soon. That makes LCEVC looks like an increasingly attractive option. And as much as people wants to believe HEVC will be taking over soon, as I would have also liked, 40% of Android dont support HEVC Hardware decode. Google Pixel 5 in 2020 dont support it or have difficulty playing HEVC files.

I was really hoping AOM, having learned its lesson with AV1, would have done a much better job with AV2 and potentially take over H.264. But as of 10 of January. This doesn't look like the case.

Spyros

13th January 2026, 00:15

VideoLAN - @videolan

First demo of upcoming new open codec AV2, with playback inside VLC4 at #CES2026 on a normal laptop!

AV2 is coming soon and it's developed by the @a4omedia
to have the best royalty-free video codec!

If you want to see the demo during #CES26, contact us!

Source: Tweet @ XCancel (https://xcancel.com/videolan/status/2009025832187252874)

https://i.imgur.com/aksgRHf.jpeg https://i.imgur.com/6T9i5LV.jpeg

kurkosdr

2nd February 2026, 11:42

Its no different from having a MP4 file with a new video codec. Why redefine the container if it works?
I wish they'd keep the container the same but change the file extension. It's so hard to explain to Average Joes and Janes that an .mp4 file can have both H.265 and H.264 content. Most people think of file extensions as being for one standard only (and backwards compatible extensions for that standard).

And yes, I know.mp4 can also have MPEG-4 ASP, but MPEG-4 ASP is commonly found in avi, so that confusion was averted back then.

Z2697

2nd February 2026, 13:17

AVIF itself is HEIF with different ext. (and "brand", but that's nothing)
HEIF and MP4 are ISOBMFF's with different ext and different structure.

kurkosdr

2nd February 2026, 16:16

AVIF itself is HEIF with different ext. (and "brand", but that's nothing)
HEIF and MP4 are ISOBMFF's with different ext and different structure.
Still, a file extension can be anything you want even if the ISOBMFF's ext is the same. Wish they had named mp4 files with HEVC mph or something similar.

hajj_3

3rd February 2026, 17:02

AV2 draft now available: https://aomedia.org/blog%20posts/AOMedia-Reflections-on-2025-and-the-Work-Ahead/

Z2697

6th February 2026, 10:39

Still, a file extension can be anything you want even if the ISOBMFF's ext is the same. Wish they had named mp4 files with HEVC mph or something similar.

We just need all the major file managers to agree on something by default... (since it's about the public perception)

rwill

6th February 2026, 12:32

Still, a file extension can be anything you want even if the ISOBMFF's ext is the same. Wish they had named mp4 files with HEVC mph or something similar.

But what about the audio in .mp4 files containing HEVC video? Do you propose to make an extra extension for every video/audio codec combination then? Or is audio so insignificant? And what about .mp4 files containing more than 1 video track? Even more extensions?

What about .ts transport streams? Way more extensions?

excellentswordfight

6th February 2026, 14:36

kurkosdr

6th February 2026, 18:01

But what about the audio in .mp4 files containing HEVC video? Do you propose to make an extra extension for every video/audio codec combination then? Or is audio so insignificant? And what about .mp4 files containing more than 1 video track? Even more extensions?

What about .ts transport streams? Way more extensions?

Audio in mp4 should have a primary audio track that is either MPEG Layer II, MPEG Layer III, AAC-LC, or something backwards compatible to AAC-LC (HE-AAC or HE-AAC v2 if you don't mind mono playback), please don't use xHE-AAC, the situation with mkv files containing AC3 and DTS as their only audio track and failing to play on various players is bad enough, please don't make mp4 the same compatibility mess. For files containing more than 1 video track, the video track that should be universally playable should be the first track.

Before HEVC came along, pretty much everyone was following the above de facto rules, and mp4 files were universally playable on any "HD" player as a result. This is why mp4 files with HEVC not playing in "HD" players are difficult to explain to Average Joes and Janes, mp4 had evolved into a de facto standard for H.264 video before that and they expect the filetype to be universally playable. A new extension like mph would have solved the confusion, much like m4a is used to clue people (and file explorers) that this mp4 file contains only audio.

When it comes to .ts transport streams, in practice, it's like MKV, you never know whether it will play on a given player, so, keep the extension unchanged.

rwill

6th February 2026, 18:17

Well, I am just happy that they stopped also making a completely new container formats with every major MPEG codec release.

We had Program Streams with Mpeg-1, Transport Streams with Mpeg-2 and that extended Quicktime Container with Mpeg-4.

Since then, nothing new, and thats totally fine I guess.

Z2697

6th February 2026, 21:07

Given long enough time average Joe's will know MP4 is not codec.

Ritsuka

6th February 2026, 21:36

Even if we had a different file extension for every container + video combination, what about audio and subtitles? It's not possible to do a separate extension for each video/audio/subtitles/whatever combination.

excellentswordfight

9th February 2026, 09:42

Before HEVC came along, pretty much everyone was following the above de facto rules, and mp4 files were universally playable on any "HD" player as a result. This is why mp4 files with HEVC not playing in "HD" players are difficult to explain to Average Joes and Janes, mp4 had evolved into a de facto standard for H.264 video before that and they expect the filetype to be universally playable.
Joes and Janes dont touch videofiles anymore, they use streaming and are on phones and tablets. People dont burn videofiles to dvds, or transfer them to usb drives to put in playbackdevices anymore to view some home video or whatever. Heck, people barely view their media in file managers at all, its in their icloud, in their instagram/snapchat library etc. They have moved on, its no point in starting doing this now, for their sake.
Given long enough time average Joe's will know MP4 is not codec.
They dont need to know it anymore, and at least in my experience power users have actually started to understand this. There has never been more resources about this stuff, when getting in to video production youtube and the internet are full or resources were this is explained good enough.

kurkosdr

27th February 2026, 22:25

I expect we'll eventually see some pretty darn good 2160p HDR 24p encodes in the 2-4 Mbps average bitrate range. AFGS1 means that we'll see the biggest savings in the content that need the highest bitrates today.
Personally, I am eager to see how 2160p HDR 24p video at 4Mbps average bitrate will look like in any format (for example AV2 or ECM), outside of specialized cases such as videos with very low motion throughout their duration. Let's assume there is no film grain either, just lots of bonafide detail that a 2160p video shot with a decent camera ought to have. I would very much like to see those claims of 4Mbps average bitrate.

At some point, you hit the limits of entropy. AV1 and VVC already lean heavily on post-processing filters to hide the damage caused by compression (leading to tons of blur that removes detail and also a "melting" effect in motion scenes), let's see how AV2 or ECM improve on that (or "improve" by leaning even more heavily on post-processing and creating an even more unnatural image).

excellentswordfight

2nd March 2026, 11:57

Z2697

2nd March 2026, 15:12

kurkosdr

2nd March 2026, 17:31

So called "post-processing" filters are actually very important.
Think the deblocking filter, since it's introduction in AVC it has become THE standard feature.
In reality most of which is implemented as in-loop filter, so that they actually contain some information of how the source should look like.

Blocking is basically an impossible (or too expensive) problem to solve without the in-loop deblocking filter.
With large blocks the next eye irritating artifact is "DCT ringing".

Yes, deblocking signalling (and post-processing signalling in general) is a good thing, but my point is, we've reached diminishing returns with HEVC and VP9. Any further post-processing introduced since then is basically a tool to game the metrics, it results in a more pleasing picture but at the expense of detail, which means the bitrate savings are fraudulent (just use a lower resolution if you aren't gonna keep the detail). That's why I am eager to see those claims of 2160p24 HDR at 4Mbps or even 6Mbps with AV2 or ECM being tested. Maybe on some types of content, but not on content with actual temporal or spatial (non-film-grain) detail.

benwaggoner

2nd March 2026, 23:03

Personally, I am eager to see how 2160p HDR 24p video at 4Mbps average bitrate will look like in any format (for example AV2 or ECM), outside of specialized cases such as videos with very low motion throughout their duration. Let's assume there is no film grain either, just lots of bonafide detail that a 2160p video shot with a decent camera ought to have. I would very much like to see those claims of 4Mbps average bitrate.
There are plenty of movies that look good in a 4 Mbps ABR with HEVC 2160p24. Peaks will be higher, but without grain or a lot of very complex detail, it's pretty achievable. Motion blur can hide many sins, and many bits can be moved out of end credits elsewhere. Not using x265 default parameters or anything, but with proper tuning it can be done, especially with CGI content with literally no kind of grain or noise.

At some point, you hit the limits of entropy. AV1 and VVC already lean heavily on post-processing filters to hide the damage caused by compression (leading to tons of blur that removes detail and also a "melting" effect in motion scenes), let's see how AV2 or ECM improve on that (or "improve" by leaning even more heavily on post-processing and creating an even more unnatural image).[/QUOTE]

excellentswordfight

3rd March 2026, 09:45

That's why I am eager to see those claims of 2160p24 HDR at 4Mbps or even 6Mbps with AV2 or ECM being tested. Maybe on some types of content, but not on content with actual temporal or spatial (non-film-grain) detail.
See above, again not AV2, but I dont see the claim to be unreasonable given whats achievable with HEVC.
Well, for that scenario, even x265 can look decent at 4Mbps. Modern clean digital sources compresses really really well.

https://limewire.com/d/RFTwE#7AXmHV0j1p
STEM2 is a very good soruce for this case, although it seems like this have shifted quite a bit in recent years were its more common for streaming first titles to have grain, its a title that image wise is very close to what we used to see from a lot of netflix originals.

hajj_3

5th March 2026, 12:38

libavif v1.4 is out: https://github.com/AOMediaCodec/libavif/releases/tag/v1.4.0

oibaf

27th March 2026, 15:51

Demonstrating Real Time AV2 Decoding on Consumer Laptops (https://aomedia.org/blog%20posts/Demonstrating-Real-Time-AV2-Decoding-on-Consumer-Laptops/)

Z2697

27th March 2026, 20:12

I personally think it's hardly any news - reference decoder, sure.

soresu

28th March 2026, 16:52

I personally think it's hardly any news - reference decoder, sure.

I mean technically it's not news because it's been posted 6 weeks late.

AOM has so many member companies yet none can field enough personnel/time to do a little PR work every week?

Z2697

28th March 2026, 17:50

I mean technically it's not news because it's been posted 6 weeks late.

AOM has so many member companies yet none can field enough personnel/time to do a little PR work every week?

Yes, it had been posted here and I saw it.
It's still hardly any news then.
https://forum.doom9.org/showthread.php?p=2027114#post2027114

They don't need "official" PR, they have fanboys.
https://forum.doom9.org/showthread.php?p=2029698#post2029698

RanmaCanada

30th March 2026, 00:00

Yes, it had been posted here and I saw it.
It's still hardly any news then.
https://forum.doom9.org/showthread.php?p=2027114#post2027114

They don't need "official" PR, they have fanboys.
https://forum.doom9.org/showthread.php?p=2029698#post2029698

Toxic fanbois who refuse to help anyone who report legitimate issues haha.

hajj_3

1st April 2026, 10:54

AVM v14.0 is now complete: https://gitlab.com/AOMediaCodec/avm/-/tags/research-v14.0.0

This will likely be the official version of AV2 v1.0. We could see an official announcement that AV2 has been ratified within the next few days.

hajj_3

8th April 2026, 19:46

AVM v14.1.0 is now complete: https://gitlab.com/AOMediaCodec/avm/-/tags/research-v14.1.0

hajj_3

10th April 2026, 09:44

AVM v15.0 milestone has been added, 4 bugs left for that: https://gitlab.com/AOMediaCodec/avm/-/milestones/20#tab-issues

ksec

11th April 2026, 17:28

AVM v15.0 milestone has been added, 4 bugs left for that: https://gitlab.com/AOMediaCodec/avm/-/milestones/20#tab-issues

I mush rather they take their time, to fine tune, or even take out certain features rather than rushed it just like they did with 1.0

But with AOM I am not having much faith.

rwill

12th April 2026, 06:56

AVM v15.0 milestone has been added, 4 bugs left for that: https://gitlab.com/AOMediaCodec/avm/-/milestones/20#tab-issues

UPDATE: Down to 2 bugs.

Very quickly for those interested, AOM have continued to improve the blur filter weights, v15.0+2 has then a better precision.

GeoffreyA

12th April 2026, 07:20

Does someone have a binary to test?

john33

12th April 2026, 07:44

Very quickly for those interested, AOM have continued to improve the blur filter weights, v15.0+2 has then a better precision.
Naughty, but amusing! :)

soresu

12th April 2026, 08:17

I mush rather they take their time, to fine tune, or even take out certain features rather than rushed it just like they did with 1.0

But with AOM I am not having much faith.

Considering they originally claimed to be launching AV2 before 2026 and we are now almost 3.5 months into 2026 without a v1/gold on the standardisation I think it's safe to say that they are being a little more cautious.

They might even have the standard spec out at the same time if the draft at av2.aomedia.org is any indication.

Z2697

12th April 2026, 15:52

Does someone have a binary to test?

Last time (months ago) I tried to build it in MSYS2 result in errors. But Linux is OK. :rolleyes:

nhw_pulsar

12th April 2026, 15:59

Very quickly for those interested, AOM have continued to improve the blur filter weights, v15.0+2 has then a better precision.

Hello rwill,

Yes that's amusing! Eager to test AV2 intra, to see how it performs with fine details/grain which seems to be the holy grail for you, but for me and for still image, I'm also interested to see how it preserves neatness of image.

GeoffreyA

12th April 2026, 16:50

Last time (months ago) I tried to build it in MSYS2 result in errors. But Linux is OK. :rolleyes:

I tried the CMake instructions for MSVC, but something was wrong.

birdie

13th April 2026, 19:28

Does someone have a binary to test?

GeoffreyA!

Why don't you have Linux installed in 2026? It's been all the rage recently ;-)

No need to wait for anyone to compile the code and trust your life with it. Compile it yourself ;-)

GeoffreyA

13th April 2026, 23:37

GeoffreyA!

Why don't you have Linux installed in 2026? It's been all the rage recently ;-)

No need to wait for anyone to compile the code and trust your life with it. Compile it yourself ;-)

The Linux rescue vessel arrived to save me, but I declined, deciding to remain aboard my sinking ship, Valiant Windows X, till the oceans overrun her. I've taken refuge on the ESU deck :-)

That's true. I did try, but had an issue with CMake. I'm not too clued up with contemporary programming practices, but, trying to learn, have made progress with Git.

Tommy Carrot

14th April 2026, 08:04

Does someone have a binary to test?

Windows binary:

https://www.mediafire.com/file/mgzzhxbtdmr3sjm/av2_260414.7z/file

Don't expect anything usable tho, the bitstream is not frozen yet, and this encoder is VERY slow right now, encoding a couple of frames takes hours.

GeoffreyA

14th April 2026, 11:06

Windows binary:

https://www.mediafire.com/file/mgzzhxbtdmr3sjm/av2_260414.7z/file

Don't expect anything usable tho, the bitstream is not frozen yet, and this encoder is VERY slow right now, encoding a couple of frames takes hours.

Much appreciated!

I got the encoding and decoding working, but it is indeed very slow at present.

Z2697

14th April 2026, 21:07

Hopefully with them taken SVT-AV1 "in", we can see a practical encoder for AV2 in a shorter time.

GeoffreyA

15th April 2026, 07:14

Yes, one hopes it won't be too hard to extend the SVT implementation to AV2. Going back to the start of how it was with AV1 would be intolerable.

excellentswordfight

15th April 2026, 11:53

The Linux rescue vessel arrived to save me, but I declined, deciding to remain aboard my sinking ship, Valiant Windows X, till the oceans overrun her. I've taken refuge on the ESU deck :-)
OT, but as someone who is pretty much forced stick to windows on my dailydriver due to Microsoft 365 and Adobe suite, I highly recommend using WSL if your not already, i do pretty much all cli/terminal stuff (scripting/python styff, encoding, compiling etc) through that.

GeoffreyA

15th April 2026, 14:14

OT, but as someone who is pretty much forced stick to windows on my dailydriver due to Microsoft 365 and Adobe suite, I highly recommend using WSL if your not already, i do pretty much all cli/terminal stuff (scripting/python styff, encoding, compiling etc) through that.

I haven't tried WSL, but thanks for the tip. I doubt whether I'd ever migrate to Linux. Which is a problem, considering the recent decline of Windows.

birdie

17th April 2026, 17:07

Has anyone tested AV2 already? I understand the reference encoder is dead slow but it doesn't take more than a couple of seconds to see what it produces in the end.

I'm extremely interested in visually lossless encoding for 1080p and 4K sources, that's when the bitrate is not extremely high but not low either and the fine details are preserved as much as possible.

GeoffreyA

18th April 2026, 09:48

birdie,

Here's a test I did last night after getting the encoding-decoding pipeline working. Using a --cq-level of 20, a bitrate of 6,244 kbps resulted. In terms of speed, it encodes about a frame per minute on my 6-core 4600G. Originally, it was slower, but raising the --threads setting reduced time by a factor of 2 to 3. Still, utilisation is far from optimal.

https://workupload.com/file/zF54U3cWCdL

You can change the -frames:v setting to control how many frames to tackle; the reference clip has 96. Be careful with FFmpeg's -y setting, which overwrites files without asking. The binaries are from Tommy Carrot above. Thanks.

:: REF.mp4 -> REF.yuv -> AV2.ivf -> AV2.yuv -> AV2.mkv (FFV1 lossless)

ffmpeg -loglevel warning -y -i __REF.mp4 -frames:v 1 -c:v rawvideo __REF.yuv

avmenc --verbose --threads=16 --width=1920 --height=1080 --fps=24000/1001 --cpu-used=8 --end-usage=q --cq-level=20 -o __AV2.ivf __REF.yuv

avmdec --verbose --threads=16 --rawvideo --output=__AV2.yuv __AV2.ivf

ffmpeg -loglevel warning -y -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 -r 23.976 -i __AV2.yuv -c:v ffv1 __AV2.mkv

Kurt.noise

2nd May 2026, 05:53

dav2d is here

https://code.videolan.org/videolan/dav2d

hajj_3

2nd May 2026, 08:18

dav2d is here

https://code.videolan.org/videolan/dav2d

Annoyingly they wrote it in C not Rust or even Zig. Those other languages would have reduced the chance of security holes. Rust was in its infancy when Dav1d was created so that was understandable but it is definitely mature now. I hope they have access to Anthropic Mythos AI to check for security holes.

Z2697

2nd May 2026, 09:45

Annoyingly they wrote it in C not Rust or even Zig. Those other languages would have reduced the chance of security holes. Rust was in its infancy when Dav1d was created so that was understandable but it is definitely mature now. I hope they have access to Anthropic Mythos AI to check for security holes.

Well well, look how rust brought down cloudflare last year.
And any SIMD optimization will just go straight into the unsafe territory.

GeoffreyA

2nd May 2026, 09:53

Z2697

2nd May 2026, 21:12

Ahh the magic of LLVM, written in C++, initially written for C/C++. :)

GeoffreyA

3rd May 2026, 05:45

A chicken-and-egg situation :)

kurkosdr

4th May 2026, 00:01

Rust vs. C/C++ reminds of Java vs. C++ in an earlier era, and how Java was specifically designed to target what James Gosling perceived as C++'s weaknesses. Well, I suppose C/C++ will always have a challenger in each age.
What killed Java was being tied to Sun's JVM, which meant a performance hit and having to install JavaSE (with the Windows installer trying to upsell you some crappy toolbar that Sun got bribed to include). Oh, and the UI not using the native OS theme, another "perk" of the JVM (back then, people cared about apps feeling native, now we've gotten so used to the GUI equivalent of brusselization (https://en.wikipedia.org/wiki/Brusselization) that we don't care).

Yes, I know you can technically compile Java into a native binary, but that's not what Sun encouraged you to do.

Another issue was Java outsourcing memory management entirely to the garbage collector, which sounded good back then, but it wasn't.

Rust has none of those issues.

That said, Java is big on business software, for Linux shops at least.

Z2697

4th May 2026, 03:20

What killed Java was being tied to Sun's JVM, which meant a performance hit and having to install JavaSE (with the Windows installer trying to upsell you some crappy toolbar that Sun got bribed to include). Oh, and the UI not using the native OS theme, another "perk" of the JVM (back then, people cared about apps feeling native, now we've gotten so used to the GUI equivalent of brusselization (https://en.wikipedia.org/wiki/Brusselization) that we don't care).

Yes, I know you can technically compile Java into a native binary, but that's not what Sun encouraged you to do.

Another issue was Java outsourcing memory management entirely to the garbage collector, which sounded good back then, but it wasn't.

Rust has none of those issues.

That said, Java is big on business software, for Linux shops at least.

And Android ;)

GeoffreyA

4th May 2026, 07:30

hajj_3

7th May 2026, 07:34

AVM 15.0.0 released: https://gitlab.com/AOMediaCodec/avm/-/tags/research-v15.0.0

Z2697

7th May 2026, 21:11

Has the specification changed in the recent versions?
Or is it just bugfix for reference implementation?

hajj_3

8th May 2026, 08:59

Has the specification changed in the recent versions?
Or is it just bugfix for reference implementation?

the draft spec still uses v13. Once AV2 has been ratified they will update the spec which will presumably be v15, v15.1 or v16.

rwill

8th May 2026, 15:06

A month ago:

AVM v14.0 is now complete: https://gitlab.com/AOMediaCodec/avm/-/tags/research-v14.0.0

This will likely be the official version of AV2 v1.0. We could see an official announcement that AV2 has been ratified within the next few days.

Now:

the draft spec still uses v13. Once AV2 has been ratified they will update the spec which will presumably be v15, v15.1 or v16.

I want the VCEG back...

kurkosdr

9th May 2026, 17:11

I want the VCEG back...

Yeah, because ISO standards never have "corrigenda" that fix mistakes (and even remove whole-ass profiles):
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Versions

If anything, ISO standards are absolutely horrible in this regard, they'll string everyone along by adding stuf such as stereoscopic 3D and 360-degree video as "versions" to the standard (instead of making those a new -potentially backwards-compatible- standard), which conveniently adds more patents to the patent pool to "justify" keeping the royalties as high as when the standard was new.

ksec

10th May 2026, 07:23

Yeah, because ISO standards never have "corrigenda" that fix mistakes (and even remove whole-ass profiles):
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Versions

If anything, ISO standards are absolutely horrible in this regard, they'll string everyone along by adding stuf such as stereoscopic 3D and 360-degree video as "versions" to the standard (instead of making those a new -potentially backwards-compatible- standard), which conveniently adds more patents to the patent pool to "justify" keeping the royalties as high as when the standard was new.

You are completely misrepresenting what rwill is saying. Not only are the profile and version two different thing, he is saying the rollout between the two are different as well as the marketing. But you manage to draw in the patent argument into it again.

Needless to say the promise of AV2 was end of last year, we are fast coming into 2H of this year already.

Again I don't want them to rush it and much rather take their time, but they shouldn't have made that promise.

kurkosdr

10th May 2026, 15:21

You are completely misrepresenting what rwill is saying. Not only are the profile and version two different thing, he is saying the rollout between the two are different as well as the marketing. But you manage to draw in the patent argument into it again.

Needless to say the promise of AV2 was end of last year, we are fast coming into 2H of this year already.

Again I don't want them to rush it and much rather take their time, but they shouldn't have made that promise.

Huh? The VCEG doesn't have a predictable release pattern for new standards either, and the fact that their spec needs to be amended with several "corrigenda" to fix various mistakes, clarify information, and add and remove profiles, means that the "Version 1" of their spec is a draft really, the fact that they slap "Version 1" on the standard for formal reasons is irrelevant.

Z2697

10th May 2026, 16:24

Huh? The VCEG doesn't have a predictable release pattern for new standards either, and the fact that their spec needs to be amended with several "corrigenda" to fix various mistakes, clarify information, and add and remove profiles, means that the "Version 1" of their spec is a draft really, the fact that they slap "Version 1" on the standard for formal reasons is irrelevant.

OK, so we shouldn't have a release H.264 specification until at least August 2024.

kurkosdr

10th May 2026, 16:36

OK, so we shouldn't have a release H.264 specification until at least August 2024.
H.264 stablized with Version 3 (and even that needed two corrigenda as Version 4 and 5 that are essential for a correct implementation), so this is your clue that VCEG wasn't ready when they released "Version 1", Version 1 and 2 were actually drafts.

But anyway, my point is that anyone who praises the VCEG for releasing a complete "Version 1" spec that isn't an officialized draft is wearing rose-tinted glasses. Same for assuming that VCEG ever stuck to any sort of release timeline.

Z2697

10th May 2026, 16:58

rwill

10th May 2026, 17:37

I always thought "patent troll" referred to something else but here we are...

kurkosdr

10th May 2026, 18:48

Oh Version 7 would be better, because it added back the slightly tweaked version of High 4:4:4 (Predictive) Profile that got removed in Version 5!
Who's to say MVC isn't important? Version 11 then!
Version 14 with it's higher level is critical for today's need!
Maybe Version 20 with BT.2020 support is even better?
Everyone has settled on Version 3 + relevant corrigenda (with the notable exception of Blu-ray 3D), nobody is broadcasting BT.2020 or HDR10 in H.264. But all those corrigenda and the addition and removal of profiles, even for the High Profile(s) that everyone is using, is what you need to know to understand that Version 1 was an officialized draft.

Z2697

10th May 2026, 20:32

Everyone has settled on Version 3 + relevant corrigenda (with the notable exception of Blu-ray 3D), nobody is broadcasting BT.2020 or HDR10 in H.264. But all those corrigenda and the addition and removal of profiles, even for the High Profile(s) that everyone is using, is what you need to know to understand that Version 1 was an officialized draft.

I've seen Baseline and Main profile in the wild (and not that rare, really). Produced to this day.
Which is pretty much Version 1.

And like I said, the removed profile is High 4:4:4 Profile and it's later added back with a little tweaking as High 4:4:4 Predictive Profile, basically with only one more possible bitdepth.
It's important, it enables lossless mode! Version 7 FTW!

Where did you see a major change in the High profile, the most popular profile?

This is too off topic so will be my last reply regarding it.

kurkosdr

10th May 2026, 22:29

I've seen Baseline and Main profile in the wild (and not that rare, really). Produced to this day.
Which is pretty much Version 1.

And like I said, the removed profile is High 4:4:4 Profile and it's later added back with a little tweaking as High 4:4:4 Predictive Profile, basically with only one more possible bitdepth.
It's important, it enables lossless mode! Version 7 FTW!

Where did you see a major change in the High profile, the most popular profile?

This is too off topic so will be my last reply regarding it.
I am not talking about backwards-compatibility changes necessarily (though this did happen with the removal of the High 4:4:4 Profile), but the fact the spec needs to be clarified and mistakes fixed. So, let's stop pretending that only AOM releases specs early and with mistakes and omissions, VCEG does too.

Z2697

11th May 2026, 10:06

I am not talking about backwards-compatibility changes necessarily (though this did happen with the removal of the High 4:4:4 Profile), but the fact the spec needs to be clarified and mistakes fixed. So, let's stop pretending that only AOM releases specs early and with mistakes and omissions, VCEG does too.

No, quite the opposite.
How many versions of AV1 specification we have seen?
2.
https://github.com/AOMediaCodec/av1-spec/tags

The problem is there's no release, not too many/early of them.

(talking about AOM thing again so I count this as back to topic :rolleyes:)

rwill

11th May 2026, 21:05

I don't know how much AV2 changed from AV1 but if its just a couple more tools they could have named it AV1 High Profile instead of naming it AV2...

kurkosdr

11th May 2026, 22:43

No, quite the opposite.
How many versions of AV1 specification we have seen?
2.
https://github.com/AOMediaCodec/av1-spec/tags

The problem is there's no release, not too many/early of them.

(talking about AOM thing again so I count this as back to topic :rolleyes:)

Again, the VCEG doesn't commit to a release timeline either, and their releases don't follow a predictable pattern either. You are judging AOM based on a non-existent standard.

kurkosdr

11th May 2026, 22:52

I don't know how much AV2 changed from AV1 but if its just a couple more tools they could have named it AV1 High Profile instead of naming it AV2...
Why? So they can confuse the heck out of normal people like the ISO people did with their 2 different standards named MPEG-4 (Visual and AVC) and their multiple non-backwards-compatible profiles for MPEG-4 Visual (SP and ASP) and MPEG-4 AVC (Baseline, Main, High Profile)?

If you've tried getting MPEG-4 AVC videos to work on portable devices on the 2000s (and eventually quit and use good ol' lowest-common-denominator MPEG-4 Visual SP in the form of the Divx Home Theater format, which at least is a consistent standard as long as you don't use anamorphic), you know what I mean. And I don't even blame the manufacturers. Good luck documenting this smorgasbord of confusingly-named standards and profiles in a manual that normal people can read.

When the WebM/AOM guys introduce a new (non-backwards-compatible) profile, at least they have the courtesy to bump the format number, if by a fractional amount (for example: VP9 -> VP9.2), they don't invent confusing standard names and profile names with the words Advanced, High, Simple, Baseline, Main etc randomly thrown in. Just try explaining to a normal person the difference between MPEG-4 Visual Advanced Simple Profile and MPEG-4 Advanced Video Coding Baseline Profile

kurkosdr

11th May 2026, 23:05

Anyway, back on topic (again), give AOM time to get AV2 in a release-worthy shape, it's not like VCEG has any predictable release pattern or commit to any release dates either.

Z2697

12th May 2026, 04:54

VP9.2 is VP9 Profile 2...

What are we doing?

I guess we have to accept that they (webm/aom) don't usually have a release.
https://www.webmproject.org/vp9/
VP9 is still draft v0.7 :rolleyes:
Let's call it VP8.7

And I don't think we have a shared understanding of backwards compatibility.
I'll share mine, it means what used to work, continue to work, not new things just magically work like old ones. ("new things" as there's actual new feature)
(of course it's possible to design something that partially work like old, and that can be called backwords compatibility as well)

GeoffreyA

12th May 2026, 07:39

And I don't think we have a shared understanding of backwards compatibility.
I'll share mine, it means what used to work, continue to work, not new things just magically work like old ones. ("new things" as there's actual new feature)
(of course it's possible to design something that partially work like old, and that can be called backwords compatibility as well)

My view of compatibility is that there are different types. On one hand, we have what used to work and still does. For example, decades-old Windows binaries continuing to work on NT. Here, it is the OS that has backwards compatibility. (Or perhaps Windows binaries have forward compatibility :-)

On the other hand, we have things like codecs, and backwards compatibility could be viewed as working on old decoders and devices. If full-spec AV2 played on AV1 decoders, it would be backwards compatible. Formats decomposing to a legacy core would be partly backwards compatible, with graceful loss of the new features.

kurkosdr

12th May 2026, 11:12

On the other hand, we have things like codecs, and backwards compatibility could be viewed as working on old decoders and devices. If full-spec AV2 played on AV1 decoders, it would be backwards compatible. Formats decomposing to a legacy core would be partly backwards compatible, with graceful loss of the new features.
Yes, that's the kind of backwards compatibility I meant. Blu-ray 3D is an example. But when it comes to those different MPEG-4 AVC profiles, the new profiles aren't backwards compatible with the old profiles, but good luck figuring that out from names like "Baseline", "Main", and "High" unless you memorize the profile names. I mean, does "Main" mean "complete" and hence is a superset of High Profile or is it a subset of "High"?

At least WebM and AOM follow a rational naming scheme VP9 Profile 1, VP9 Profile 2.

And I don't think we have a shared understanding of backwards compatibility.
I'll share mine, it means what used to work, continue to work, not new things just magically work like old ones. ("new things" as there's actual new feature)
That's one definition of backwards compatibility, and "MPEG-4" fails even at that: For example, there is no guarantee a MPEG-4 AVC player will play MPEG-4 Visual streams (Blu-ray players can play MPEG-4 AVC but aren't required to play MPEG-4 Visual, and I am not sure Blu-ray players are required to play MPEG-4 AVC Baseline and Main either, since High Profile is not an exact superset of Baseline and Main).

Z2697

12th May 2026, 11:44

It looks like for WebM/AOM things work in backwards, you have numbered profiles in VP8.7, but then in AV1 you have Main, High, and Professional.

MPEG-4 is a big thing, they are different parts. There's no such thing as "backward compatibility" between them.
If you want "inter-compability" maybe you should also design a decoder that decodes the AAC (MPEG-4 Audio) "layer" (imagine there is such layer) of MPEG-4 Visual?
Important note: It's not the same as being able to decode both formats, it's decoding AAC "out of" MPEG-4 Visual.
And even AAC is just a part of MPEG-4 Part 3.

What are we doing really?

The name doesn't matter, VP9 is a draft forever and people seem to be happy about it.
AV2 is a draft but probably there will be a finalized version, still doesn't matter.
What matters is the joke about "end of 2025".

Kurt.noise

22nd May 2026, 04:22

Finally, the first release of AV2 is officially planned next week (https://github.com/AOMediaCodec/avm/commit/87aa8dc44e8a40f992604111a5ce83cf413ec9b7)...

btw, a dav2d x64 Windows build for those whom interested : https://www.mediafire.com/file/m0hgq5tdabsggf8/dav2d-0.0.1-142_x64.7z/file

Jamaika

22nd May 2026, 08:54

Does anyone know where to download free av2 samples to test dav2d in ffmpeg?

GeoffreyA

22nd May 2026, 09:10

Does anyone know where to download free av2 samples to test dav2d in ffmpeg?

Don't know, but you can use this script to encode short clips:

https://forum.doom9.org/showthread.php?p=2030467#post2030467

Jamaika

23rd May 2026, 12:29

Thanks for the codecs and samples

ksec

24th May 2026, 12:57

H.264 stablized with Version 3 (and even that needed two corrigenda as Version 4 and 5 that are essential for a correct implementation), so this is your clue that VCEG wasn't ready when they released "Version 1", Version 1 and 2 were actually drafts.

But anyway, my point is that anyone who praises the VCEG for releasing a complete "Version 1" spec that isn't an officialized draft is wearing rose-tinted glasses. Same for assuming that VCEG ever stuck to any sort of release timeline.

The point is VCEG never promised any time line in the first place. It is ready when it is ready. But AOM has repeatedly stated unrealistic timeline and roadmap in nearly all instances.

Do we need to go back we were suppose to have AV2 in 2020 and AV3 in 2022?

Overpromise and underdeliver is what they have done not just AOM but since the days on On2. Plenty of people wished they have learned their lesson with AV1, but all signs points to not so much so.

Anyway back to the topic. Av2 releasing soon and most importantly, dav2d is in really good shape from the get go!. Looking forward to testing results and hopefully some AV2 image codec comparison against JPEG XL.

hajj_3

24th May 2026, 20:20

But AOM has repeatedly stated unrealistic timeline and roadmap in nearly all instances.

Do we need to go back we were suppose to have AV2 in 2020 and AV3 in 2022?

Overpromise and underdeliver is what they have done not just AOM but since the days on On2.

Not really. They originally said that but after speaking to manufacturers they realised that manufacturers don't want to have to use more silicon every 3yrs for a new codec. They other reason is that a know codec every 3yrs would see little adoption. Having a 8yr gap between AV1 and AV2 was a good idea as AV1 hardware decoders are now in all computers and all high end smartphones. Low end phones are supposed to get AV1 support this year or next year.

GeoffreyA

25th May 2026, 05:50

Low end phones are supposed to get AV1 support this year or next year.

On newer versions of Android, dav1d is being used, so even in the absence of hardware decoding, AV1 should play quite well everywhere.

benwaggoner

27th May 2026, 00:22

On newer versions of Android, dav1d is being used, so even in the absence of hardware decoding, AV1 should play quite well everywhere.
...absent premium content with a hardware DRM requirement...

Z2697

27th May 2026, 01:15

...absent premium content with a hardware DRM requirement...

How is DRM tied in with decoder?

rwill

27th May 2026, 02:34

How is DRM tied in with decoder?

The pictures never leave the GPU I guess. Where 'GPU' is some protected hardware safe space that is not accessible even by villain hackery.

kurkosdr

28th May 2026, 15:23

On newer versions of Android, dav1d is being used, so even in the absence of hardware decoding, AV1 should play quite well everywhere.
Please tell me that Google hasn't started doing on the YouTube app and YouTube mobile that annoying thing they are doing on YouTube desktop, where they'll serve you AV1 even if your computer only has H.264 hardware acceleration? I had to install h264ify to prevent some old laptops from doing a vacuum cleaner impression while watching YouTube. On mobile it will drain the battery like no tomorrow.

GeoffreyA

28th May 2026, 16:15

Please tell me that Google hasn't started doing on the YouTube app and YouTube mobile that annoying thing they are doing on YouTube desktop, where they'll serve you AV1 even if your computer only has H.264 hardware acceleration? I had to install h264ify to prevent some old laptops from doing a vacuum cleaner impression while watching YouTube. On mobile it will drain the battery like no tomorrow.

I tested it now on the Gamers Nexus video, and on the computer, it uses AV1, but on my phone, which does not have AV1 hardware, it uses VP9; so they seem to be querying the hardware properly.

hajj_3

28th May 2026, 20:00

AV2 v1.0.0 has been released!!!

https://github.com/AOMediaCodec/avm/releases/tag/v1.0.0

Z2697

28th May 2026, 21:31

hajj_3

28th May 2026, 21:41

Is it the release of specification or the reference software?
https://av2.aomedia.org/ This thing still says draft.
https://web.archive.org/web/20260528203129/https://av2.aomedia.org/ For future reference.

It is the reference encoder and i think decoder. They haven't updated their website yet. Hopefully within the next few days they will make a blog post and release the final specification document.

Z2697

29th May 2026, 03:52

Why they love trolling...

Jamaika

29th May 2026, 08:18

AV2 v1.0.0 has been released!!!

https://github.com/AOMediaCodec/avm/releases/tag/v1.0.0
Finally, the first release of AV2 is officially planned next week (https://github.com/AOMediaCodec/avm/commit/87aa8dc44e8a40f992604111a5ce83cf413ec9b7)...

btw, a dav2d x64 Windows build for those whom interested : https://www.mediafire.com/file/m0hgq5tdabsggf8/dav2d-0.0.1-142_x64.7z/file
Now that it is released, you can test and check compatibility.
So I decided to test the AV2 decoder. I generated AV2 images using a webp2 pump to see if they could be displayed.
https://chromium.googlesource.com/codecs/libwebp2/+/d5920d8fe6abb5b3ba9b9bef3924f18433dd6d37
https://github.com/AOMediaCodec/avm/commit/f2364007035db686b220e3ec17d17abca2037328
https://code.videolan.org/videolan/dav2d/-/commit/ca6c40055baff65f4f7dacc4484bbf17c5251426

I'm having a problem with the AV2 encoder. One definition is deleted, but that's irrelevant. The images are being generated, but how do I decode them?
I used the latest 8-bit DAV2D. Error messages are displayed. I corrected the errors as best I could, but the image won't decode.
I used the AVM decoder. To my surprise, the image converted correctly. Unfortunately, decoders do not show input file information. It's unclear whether the image is 8-bit or 12-bit.

avmdec_avx.exe input_8bit.av2 -o output_8bit.yuv
avmdec_avx.exe input_12bit.av2 -o output_12bit.yuv //fantasy, distant future, added TEST_ONLY_12BIT_PROFILE
dav2d_avx2.exe -i input_8bit.av2 -o output_8bit.yuv //only 8bit
Error decoding frame: Invalid argument
Defaul is MAIN_444_10_IP1 that means InternalBitDepth is no less than 10. How is an 8bit decoder supposed to decode this?
ewp2_avx.exe input_12bit.y4m -size -q 100 -nometadata -effort 7 -csp 0 -o output_???bit.wp2
av2enc_avx.exe (-depth 12) -q 100 -444 -size 280x420 -effort 7 -threads 4 -pass 1 -tune ssim input_???bit.wp2 -d output_12bit.av2

Decoder dav2d 0.0.1
https://www.sendspace.com/file/duxvuf
Codec AVM 1.0.0
https://www.sendspace.com/file/cvevjm
Image webp2 0.0.1
https://www.sendspace.com/file/rj8ynd

Z2697

29th May 2026, 19:06

It looks like Jamaika's artisanal build process has meaning when the official build system doesn't work :) On Windows.
I'd say I'm a experienced Linux user but sadly my main system is still W10.

Oh okay I just had to read the actual cmake codes instead of just "trust it"...

This works in MSYS2:
cmake -DCONFIG_ML_PART_SPLIT=0 -DCONFIG_DIP_EXT_PRUNING=0 -DENABLE_TESTS=0 -DENABLE_TESTDATA=0 -Bbuild
But lacks "AI" features, whatever that is...

Spyros

30th May 2026, 23:31

The final AV2 specification (v1.0.0) has been released!

https://av2.aomedia.org/

Z2697

31st May 2026, 10:03

Zebulon84

31st May 2026, 11:28

When they announced (https://aomedia.org/press%20releases/AOMedia-Announces-Year-End-Launch-of-Next-Generation-Video-Codec-AV2-on-10th-Anniversary/) "year-end release", we all understood Calendar year 2025, but they probably meant Academic year 25-26 ;)

GeoffreyA

31st May 2026, 11:54

So they were just having sometime to update the website.
Now let's wait for SVT-AV2!
Hopefully it's not gonna take long, since the teams are working closely- I suppose.

(Great, so the AOM calendar is like half a year behind real world.)

Yes, this time we want to go straight to SVT-AV2 and not waste a couple of years with the tortoise-like reference encoder.

hajj_3

31st May 2026, 15:44

Dav2D blog post: https://web.archive.org/web/20260531130034/https://jbkempf.com/blog/2026/dav2d/

oibaf

1st June 2026, 10:12

Dav2d is already packaged in Debian (14) and Ubuntu (26.10):
https://tracker.debian.org/pkg/dav2d
https://launchpad.net/ubuntu/+source/dav2d

ksec

4th June 2026, 16:03

Not really. They originally said that but after speaking to manufacturers they realised that manufacturers don't want to have to use more silicon every 3yrs for a new codec. They other reason is that a know codec every 3yrs would see little adoption. Having a 8yr gap between AV1 and AV2 was a good idea as AV1 hardware decoders are now in all computers and all high end smartphones. Low end phones are supposed to get AV1 support this year or next year.

That was their excuses. As if they were completely new to codec development. Nearly everyone in the codec community, including professional see it as lies.

But they got the press release, and all of their supporter to rally behind, suggesting because it is Google, a codec every 2-3 years was possible. Because Google could somehow afford to design the hardware decoder IP and give it to everyone for free. Guess how that turned out?

rwill

5th June 2026, 06:56

GeoffreyA

5th June 2026, 11:27

Z2697

5th June 2026, 12:23

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.

Hopefully, juliobbv or BlueSwordM could comment. After the nightmare early days of libaom, whose speed and Instagram plastic were renowned, I don't think many an enthusiast will want to touch the reference encoder.

I guess if power efficiency is considered, the ASIC is still the inevitable choice.

libaom is/was semi-usable at least, but avm is like completely unusable (slow)...

GeoffreyA

5th June 2026, 18:59

libaom is/was semi-usable at least, but avm is like completely unusable (slow)...

I think it took me about 45 minutes for 96 frames.

kurkosdr

5th June 2026, 21:55

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.
AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

soresu

6th June 2026, 00:06

Perhaps if there were a halfway approach: instead of a hard-coded ASIC, a generalised encoder-decoder unit whose firmware could be updated with new codecs.

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.

soresu

6th June 2026, 00:19

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

I think GPGPU decoding is technically possible for modern codecs like AV1/VVC, but the higher complexity, multiple references and various other things mean that running it is like an emulator ubershader (shader based console GPU emulation) on steroids.

From what I've heard over the years it just doesn't play well to a GPUs strengths past a certain level of complexity for a program to be executed purely in GPU, and splitting up the workload between CPU and GPU for hybrid compute requires super tight integration, low latency and high bandwidth of the likes you don't see in many SoCs.

It might be worth Apple's time and money to do it, but they'd probably just wait for their own ASIC to mature, while using dav2d in the meantime.

Z2697

6th June 2026, 07:27

AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

The page literally says it's ASIC.

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.

soresu

6th June 2026, 08:30

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.

I saw that, and I could definitely see the interest for video editors with non Apple hw (includes ProRes ASICs at this point?).

Do you know if anyone has done power consumption comparisons?

Blue_MiSfit

6th June 2026, 08:52

I'd be astonished if vulkan is more efficient than videotoolbox native hardware decode

soresu

6th June 2026, 09:20

I'd be astonished if vulkan is more efficient than videotoolbox native hardware decode

I meant CPU sw decode vs GPGPU decode.

Z2697

6th June 2026, 12:29

I meant CPU sw decode vs GPGPU decode.

When I said "performence" I did mean both speed and power consumption...
But I can't (or not willing to) control my system precisely for this test, so take it with a grain of salt.
Depending on the design of the chip(s), for example Intel's efficiency cores, things may be more interesting.
My system has not much to do with efficiency, so they are just about the same. (modern chips are quite efficient and I like it this way, but efficiency is only in the back of my mind, faintly, you know, when I hear fans...)

So I said when doing fast transcoding, i.e. decoding at that speed will be a significant portion of the load, it's worth offloading to GPU.
Otherwise, I don't really see many use case... well maybe doing native GPU pipeline without the need to pump raw pixel data between CPU/RAM and GPU/VRAM? IDK.

GeoffreyA

6th June 2026, 14:25

AMD tried doing that in some high-end R600 GPUs (using the GPGPU cores, aka the pixel shaders, to do video decoding), but power efficiency was below ASIC decoding and users didn't receive it well:
https://en.wikipedia.org/wiki/Unified_Video_Decoder#Availability

I would prefer a compromise: If ASIC decoding is not available, use GPGPU decoding (that can be added later via driver updates), but I haven't seen anyone do this (either GPU vendor or player/browser using OpenCL).

It might be just marginally more efficient than an optimised software decoder.

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.

Something along these lines, but generic in the sense of defining common functions across decoders and encoders, then tying it up with codec-specific stuff that can be changed.

ksec

6th June 2026, 20:33

A new codec every 2-3 years makes sense, even if the actual coding gains are small.

YouTube just needs to re-encode everything, consumers will need to buy a new phone and older content illegaly downloaded from YouTube will become deprecated. Cannot let a chip grow every iteration beyond some point so older YouTube codecs can be kicked out of new chips.

Android devices are just Google Services access points anyway, and Google wants to push ahead. No need to orient at a slow and dysfunctional MPEG market.

It really doesn't.

AV2 currently offers 20-30% BD-Rate took nearly 8 years. If you could make a new video codec very 2-3 year. Let's assume you can. You will still need at least 1 year to design the ASIC that is low power, which is already an impossible task. You will need another 1 year to integrated into the SoC. On the assumption your SoC release schedule fits into next Smartphone sales cycle perfectly that is at least 6 - 8 months validation process.

The hardware alone is 2-3 years lead time minimum *after* your codec development cycle. And that is assuming the codec has the conformance, testing kit and everything in place.

>YouTube just needs to re-encode everything

Google is already having issues just to keep up with new video upload encoding, excluding storage cost problems. You can't re-encode a Video which has little to zero adoption on Mobile. When 80% of the total consumption on Youtube, 95%+ if you are Facebook, Instagram or TikTok on mobile.

Even with Apple, a new mobile phone with new SoC only sell about 100M unit in total, that is ~8% of their iPhone user spread across the world. It is far lower on Android.

Let's just assume 8%, which is not even a best case but unrealistic scenario. You will have to encode AV2 for 8%, AV1 for 30%, H.264 for the rest. And if you do 2 -3 years, You will have AV3 for 8%, AV2 for 24%, AV1 for 10%? and Rest H.264?

Upgrading firmware and GPGPU acceleration is even worse. Simply because vendors are not going to upgrade their phone for free. It requires additional work and validation and man power. Android took years to even have long form of Software and security support. Forget about firmware upgrade without the help of Qualcomm, MediaTek working along side all Chinese Vendors. Their interest do not align.

And the end of the day. What is the point of a new codec? Do new codec really help to sell new Smartphone? It doesn't. It only helps Google. If a new codec requires constant work on hardware and die space, which has additional cost, what is the incentive for hardware side to adopt it? Other than perhaps great marketing to minor group of people? Google might have a better excuses if their Pixel Tensor SoC are leading the pack, but they are not.

None of that is new, It wasn't even new in 2016. But the recent update from both AOM and MPEG / VCEG has finally admitted they will now need to consider adoption cycle. And may be we should stop fantasying new video codec without hardware adoption.

Z2697

6th June 2026, 20:48

I think rwill is being sarcastic :rolleyes:

hajj_3

6th June 2026, 22:37

What is the point of a new codec? Do new codec really help to sell new Smartphone? It doesn't. It only helps Google. If a new codec requires constant work on hardware and die space, which has additional cost, what is the incentive for hardware side to adopt it? Other than perhaps great marketing to minor group of people?

A new codec saves bandwidth costs for youtube, netflix, amazon prime video, appletv, disney+ etc not just 1 company. It also reduces bandwidth for consumers which is particularly beneficial when using your phone's data contract allowance. That saves consumers money as they can have a cheaper data plan. It also helps to reduce data congestion during peak times on 4G/5G as some major cities have slow speeds during peak time due to excessive bandwidth usage.

Another advantage is faster startup of videos. Videos only play once they have download a bit of the beginning of the video. AV2 will have a smaller filesize so if you want to download the first 3 seconds it will download it faster. This is particularly beneficial for platforms like tiktok and instagram.

rwill

6th June 2026, 22:48

I think rwill is being sarcastic :rolleyes:

Yeah. I have now read my comment again and still thought this is obvious. Shows that at least ksec seems to be subjected to a constant stream of nonsense his mind has to fight through daily, breaking his sarcasm detector. I blame western social media.

In China they have made it so that only certified and approved people can comment on certain topics on their social media. If the deterioration of the intellectual level in the western internet continous we might have to establish a similar approach to save our society.

rwill

6th June 2026, 23:17

A new codec saves bandwidth costs for youtube, netflix, amazon prime video, appletv, disney+ etc not just 1 company. It also reduces bandwidth for consumers ...

Oh boy do I have news for you. There have been hardly real bandwidth savings in the last 10+ years in the end-consumer codec space. What happened is that the recent codecs have special tools which help for special content cases, but these improvements are not generic.

A generic movie or UGC is not special, its generic. The tools arent helping there. Saving 25-50% bandwidth with VVC or AV2 switching from HEVC or AV1 is marketing talk. Sure enough, if the plan is to cut bitrate by 30% the streaming services or YouTube can do just that, the engineers will have to if they want to keep their job, but it will hurt quality and thus QOS. And consumers will notice. The businesses will most likely do the cut anyway.

There are also quality to size gains coming from algorithmic encoder improvments that are generic, but the % gain they state with new codecs is most of the time only referencing the state of the encoder implementation there was when the old standard was released, not the state of the art when the new standard released. So more unreal alleged gains for the new codec.

Thats some reasons why x264 still beats recent codec encoder implementations frequently in subjective quality given sane settings.

GeoffreyA

7th June 2026, 08:10

In China they have made it so that only certified and approved people can comment on certain topics on their social media. If the deterioration of the intellectual level in the western internet continous we might have to establish a similar approach to save our society.

It's as Aldous Huxley noted in Brave New World Revisited, that more than the battle between truth and falsehood, it was the irrelevant and unreal that would drown out everything else. In true BNW-style, it tends to distract us from the real issues at hand, or, in film terms, what the Matrix is.

"In regard to propaganda the early advocates of universal literacy and a free press envisaged only two possibilities: the propaganda might be true, or it might be false. They did not foresee what in fact has happened, above all in our Western capitalist democracies—the development of a vast mass communications industry, concerned in the main neither with the true nor the false, but with the unreal, the more or less totally irrelevant. In a word, they failed to take into account man's almost infinite appetite for distractions."

Z2697

7th June 2026, 10:14

Oh boy do I have news for you. There have been hardly real bandwidth savings in the last 10+ years in the end-consumer codec space. What happened is that the recent codecs have special tools which help for special content cases, but these improvements are not generic.

A generic movie or UGC is not special, its generic. The tools arent helping there. Saving 25-50% bandwidth with VVC or AV2 switching from HEVC or AV1 is marketing talk. Sure enough, if the plan is to cut bitrate by 30% the streaming services or YouTube can do just that, the engineers will have to if they want to keep their job, but it will hurt quality and thus QOS. And consumers will notice. The businesses will most likely do the cut anyway.

There are also quality to size gains coming from algorithmic encoder improvments that are generic, but the % gain they state with new codecs is most of the time only referencing the state of the encoder implementation there was when the old standard was released, not the state of the art when the new standard released. So more unreal alleged gains for the new codec.

Thats some reasons why x264 still beats recent codec encoder implementations frequently in subjective quality given sane settings.

I do think most of the time those numbers can reflect generic improvement.
It's just intra prediction, motion estimation, residual transform encoding, in-loop filter(s), and entropy encoding,
I tend to think there's no/very few special cases, because what we want to encode is some sequence of the illusion of something moving on the screen after all.

It's just the the numbers are exaggerated.
And some contents rely more on one area, but the number may represent all combined.
For example, fast chaotic motions rely more on intra prediction.

rwill

7th June 2026, 11:05

I do think most of the time those numbers can reflect generic improvement.

Well, lets take the tool ALF, the Wiener based adaptive loop filter. Great BD-Rate gains using PSNR as metric. Lets say 5%. But is it really a generic 5% improvement when, in addition to coding artifacts, small details are filtered away as well and the picture looks like as if some strong selective gaussian blur with large radius has been applied? My opinion is "No".

Z2697

7th June 2026, 18:28

Well, lets take the tool ALF, the Wiener based adaptive loop filter. Great BD-Rate gains using PSNR as metric. Lets say 5%. But is it really a generic 5% improvement when, in addition to coding artifacts, small details are filtered away as well and the picture looks like as if some strong selective gaussian blur with large radius has been applied? My opinion is "No".

Yeah, jump down three lines from where you quote...

And it's like the SAO situation, the implementation matters.

I think ALF in VVC is similar to CDEF in AV1? (restoration filter has a Wiener mode but it's on a larger level, correct me if I'm wrong)
It's not really that bad...

Z2697

7th June 2026, 21:50

The AV2 sample in VQAnalyzer is too low quality (blame avm default setting), so I encoded the y4m sample with a higher quality, CQP 140.
Maybe too high (bigger than AV1 sample), but the encoder is dead slow so I don't want to encode another one.
Encoder is built by Clang in MSYS2 clang64 environment, without the ML (TFLite) features, there's a crash in

if (sms_tree != NULL) sms_tree->partitioning = PARTITION_NONE;

I commented out this thing...
(I later found out that it's "caused" by a inlined function that called this function, so perhaps I'll noinline it and do another encode... later...)
(sms_tree is function parameter and should be NULL in this call but some weird thing make the inlined call pass in 0x85008500850085 ...or some other garbage similar to it)
https://pixeldrain.com/u/6xs2X11a

kurkosdr

8th June 2026, 14:16

The page literally says it's ASIC.
Read more carefully, it's wasn't an ASIC on the Radeon HD 2900 XT.

Most of the Radeon HD 2000 series video cards implement the UVD for hardware decoding of 1080p high definition contents.[31] However, the Radeon HD 2900 series video cards do not include the UVD (though it is able to provide partial functionality through the use of its shaders), which was incorrectly stated to be present on the product pages and package boxes of the add-in partners' products before the launch of the Radeon HD 2900 XT,

kurkosdr

8th June 2026, 14:20

You mean an FPGA?

With video codecs getting increasingly complex to extract increasingly diminishing returns I'm not certain an FPGA could handle it, IIRC they tend to be pretty density challenged per mm2 relative to ASICs.
Something along these lines, but generic in the sense of defining common functions across decoders and encoders, then tying it up with codec-specific stuff that can be changed.

How would an FPGA help here? Once an FPGA is programmed, it functions as an ASIC with worse power consumption and heat generation (compared to an ASIC made with the same node process). FPGAs can't be reprogrammed, not that even if they could, most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.

What you could have is an ASIC that allows low-level access to features such as IDCT, motion prediction, deblocking etc so those can be used by software to decode new standards, but considering how much the algorithms of those things change with each new standard, I doubt something like that can exist. For example, DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST), so your low-level access to the ASIC's functions is worthless, since you'll have to fall back to software processing anyway.

For anyone who might be interested, GPGPU decoding of prores and ffv1 etc. is availble in FFmpeg.
Performance is roughly same as CPU.
The only worth part I can think of is offloading to GPU, so when doing fast transcoding the CPU can have more resource.
Aww... sucks. I expected GPGPU decoding to give a massive boost compared to CPU decoding, just like it does for cryptocurrency mining, since video decoders are inherently parallel due to the fact the input (the compressed bitstream) is already split into multiple independent macroblocks.

Z2697

8th June 2026, 16:13

FPGAs can't be reprogrammed

They can, that's the purpose of FPGA...

most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.

That's because FPGA is not usually end up in products the general consumer would use.
If they do, they will be designed in such way that a driver update, or maybe lower level, VBIOS update, can reprogram the FPGA.

Z2697

8th June 2026, 16:24

Read more carefully, it's wasn't an ASIC on the Radeon HD 2900 XT.

OK... so it's not like they had no other choice, they essentially did decoding design twice just to save some ASIC chips on ironically, high-end GPUs...
Weird choice.

Perhaps they need the die area to put in extra GPU cores?

Z2697

8th June 2026, 19:49

kurkosdr

8th June 2026, 23:01

They can, that's the purpose of FPGA...

That's because FPGA is not usually end up in products the general consumer would use.
If they do, they will be designed in such way that a driver update, or maybe lower level, VBIOS update, can reprogram the FPGA.
It depends on the FPGA, but if you want to get anything resembling good performance-per-watt, you need the kind of FPGAs that cannot be reprogrammed once programmed (antifuse-based).

And if you don't care about performance-per-watt but still want to keep the CPU free for other tasks, GPGPU decode is right there.

kurkosdr

8th June 2026, 23:11

OK... so it's not like they had no other choice, they essentially did decoding design twice just to save some ASIC chips on ironically, high-end GPUs...
Weird choice.

Perhaps they need the die area to put in extra GPU cores?
The spat between GPU vendors for the all-important "performance crown" was insane during the 90s and 2000s, and it was the cause of several paper launches, officially-overclocked hardware of dubious reliability (FX 5800 Ultra), rushed/sloppy engineering causing failures even within the warranty period (Nvidia bumpgate), and cheats in the drivers that would embarrass the GPU vendor (see: ATI quack scandal).

Eventually, Nvidia realized during its Fermi "mistake" that gamers don't care about power efficiency or high-end GPUs fitting a certain price bracket, so the gaming GPU industry shifted to brute force (in the form of huge transistor counts and comically oversized cooling solutions).

But back in the 2000s, the die area occupied by the video-decoding circuitry mattered.

excellentswordfight

9th June 2026, 07:48

FPGAs can't be reprogrammed, not that even if they could, most users would buy an FPGA (re-)programmer and disassemble their devices to pop out the chip to reprogram it.
It depends on the FPGA
Oh common, like you knew what a antifuse fpga was when you made the first post. SRAM-based fpga are by far the most common type.

I work with fpga-based products all the time, vendors ships new features - comes with an update, fpga is re-programmed.

If a updatable hw-decoder using an fpga is practical from a perf/w standpoint though? No idea, out of my expertise.

But on the notion of having a fpga on a more general purpose chip, If memory serves my right, I do think that at some point Intel had Xeons with a fpga on the same package, not sure what happened with that though.

kurkosdr

9th June 2026, 09:01

Oh common, like you knew what a antifuse fpga was when you made the first post. SRAM-based fpga are by far the most common type.
FYI it's common knowledge that some FPGAs can't be reprogrammed and they are the ones getting good performance-per-watt.

But anyway, if you think you know what I know better than me, go ahead.

excellentswordfight

9th June 2026, 09:55

FYI it's common knowledge that some FPGAs can't be reprogrammed and they are the ones getting good performance-per-watt.

But anyway, if you think you know what I know better than me, go ahead.
I was not the one claiming that they, and not some, cannot be re-programmed, and if they could they needed a re-programmer. It only sounds you are trying to backtrack cause you did a bit of googling, and started to talk about a niche type of FPGA that would be completely irrelevant to the discussions as it was specifically about having the ability to update the hardware with new de-coders.

And apparently I do know more given the nonsens in your first post which no one familair with fpgas would have wrote.

kurkosdr

9th June 2026, 10:19

I was not the one claiming that they, and not some, cannot be re-programmed, and if they could they needed a re-programmer. It only sounds you are trying to backtrack cause you did a bit of googling, and started to talk about a niche type of FPGA that would be completely irrelevant to the discussions as it was specifically about having the ability to update the hardware with new de-coders.

And apparently I do know more given the nonsens in your first post which no one familair with fpgas would have wrote.
FYI I was taught about FPGAs that are programmed by blowing fuses (or more accurately, anti-fuses) in uni, but what do I know about myself.

rwill

9th June 2026, 11:17

FYI I was taught about FPGAs that are programmed by blowing fuses (or more accurately, anti-fuses) in uni, but what do I know about myself.

Wild, were you also taught at that uni that "DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST)" ?

FYI: I too blew some fuses at the uni I got taught things, even so many that the lecturer suggested to me skipping practical lab assignments after a while.

kurkosdr

9th June 2026, 12:53

Wild, were you also taught at that uni that "DST was introduced in HEVC, so any H.264-era ASICs that implement only IDCT (inverse DCT) won't be able to do inverse DST (aka decode DST)" ?

FYI: I too blew some fuses at the uni I got taught things, even so many that the lecturer suggested to me skipping practical lab assignments after a while.

(oh look, the forum's resident arse is here)

Anyway, where exactly is the wrong in my statement? While DST existed as a mathematical concept since forever, it was introduced in HEVC (whether it was introduced in video compression standards or in cauliflower agriculture, I will leave that to the reader's ability to fill-in context to figure it out). So, any ASIC that can only do IDCT won't be able to do IDST (because such feature is never exposed anyway), so you'll have to fall back to software. It's one example of how, no matter how much fine-grained control you have over the ASIC, you can't re-use an existing ASIC to decode new video compression standards without falling back to software at least for some things.

hajj_3

9th June 2026, 13:22

The Alliance for Open Media just announced AV2: https://aomedia.org/press%20releases/Alliance-for-Open-Media-Releases-AV2-Codec/

Surprisingly they didn't include any benchmarks in their blog post.

rwill

9th June 2026, 14:37

OK... so it's not like they had no other choice, they essentially did decoding design twice just to save some ASIC chips on ironically, high-end GPUs...
Weird choice.

Perhaps they need the die area to put in extra GPU cores?

Everyone is guessing here, and so am I, but what I could gather is that the Radeon HD 2900 has a R600 chip in 80nm process, the Radeon HD 2600 has a RV630 chip in 65nm process and the Radeon HD 2400 has a RV610 chip in 65nm process, of which the first available silicon revision had their UVD in a broken state (also called HD 2350).

So, different chips in different states of development and verification launched at around the same time I guess, as was tradition.

rwill

9th June 2026, 14:45

FPGAs...

I don't know much about FPGAs, except that FPGA stands for Field Programmable Gate Array, where "Field" refers to the environment they operate in. As in, they can be (re-)programmed in the field.

kurkosdr

9th June 2026, 21:25

I don't know much about FPGAs, except that FPGA stands for Field Programmable Gate Array, where "Field" refers to the environment they operate in. As in, they can be (re-)programmed in the field.
Being field programmable and being field re-programmable are not the same. In the same way that a CD-R is recordable but not re-recordable.

Z2697

9th June 2026, 21:43

Who would have thought, that the reference encoder should be deterministic? :rolleyes:

e9c4ad5cc80867d5c54dcd5367787975d1e70148 /home/bruh/ml.ivf
0784e463b95eb9d8c060e2f389142c343d5755ea /home/bruh/ml,.ivf

birdie

10th June 2026, 09:47

Who would have thought, that the reference encoder should be deterministic? :rolleyes:

This mustn't be happening. Are they using AI or what?

Z2697

10th June 2026, 12:11

Probably not a AI thing.
Maybe it has two states, sometimes the "baseline_gf_interval" starts as 10, sometimes it's 8.
Is there more? IDK, I haven't run it a lot of times.

Jamaika

11th June 2026, 08:09

A few progress summaries of AVM AVX2 decoding of photos and videos.
AV2 photos can be created in my ffmpeg and libwebp2 8bit. Here are the results.
Surprisingly, the latest dav2d decoder decoded 8bit AV2. However, I don't know how to decode a 12bit photo, even with a 16bit decoder.
4K photos take me a good 5 minutes to create.
For those curious, I've added my files in gcc. I know VS2026 is more popular.
I don't know why cpu-used has to be zero or one for the avm encoder to work.

https://github.com/AOMediaCodec/avm/commit/457cd58681a747465661baccb1f32095bc5b7774
https://www.sendspace.com/file/gln7fc

https://code.videolan.org/videolan/dav2d/-/commit/9f497073e1cce56830e475ebfc110be2874d7e72
https://www.sendspace.com/file/joqcx9

https://chromium.googlesource.com/codecs/libwebp2/+/d5920d8fe6abb5b3ba9b9bef3924f18433dd6d37
https://www.sendspace.com/file/5opq0e

ffmpeg_vulkan_avx2.exe -loglevel warning -y -i "image_21447_24bit.png" -y -c:v libavm-av2 -an -qp 52 -vf "format=yuv420p" -frames:v 1 -cpu-used 8 -still-picture 1 -tune ssim output_avm_08bit.av2
ffmpeg_vulkan_avx2.exe -loglevel warning -y -i "image_21447_24bit.png" -y -c:v libavm-av2 -an -qp 42 -vf "format=yuv444p12le" -frames:v 1 -cpu-used 8 -still-picture 1 -tune ssim output_avm_12bit.av2
cwp2_avx2.exe "image_21447_24bit.png" -info -q 100 -8bits -mt -effort 7 -uv_mode 2 -csp 0 -o image_21447_24bit.wp2
av2enc_avx2.exe -q 100 -444 -effort 7 -threads 4 -pass 1 -tune ssim image_21447_24bit.wp2 -d image_21447_24bit.av2
dav2d_xxbit_avx2.exe -i input_xxbit.av2 -o output_xxbit.y4m
What can be said about videos? It's already a bit slow. Very slow encoder. Pervasive blur. The lower the framerate, the more blur. IVF files don't open in DAV2D. I tested it for HD at 100 frames at 60 fps. I think we'll have to wait another six months.

AVM IVF sample video:
avmenc_avx2.exe --verbose --threads=16 --cpu-used=1 --end-usage=cbr --target-bitrate=3000 -o __AV2.ivf __REF.y4m
https://www.sendspace.com/file/u2br2t

GeoffreyA

11th June 2026, 19:56

Best to wait for SVT-AV2 and ignore the reference encoder.

rwill

12th June 2026, 04:39

Best to wait for SVT-AV2 and ignore the reference encoder.

Any development news?

And where is x266? xD

GeoffreyA

12th June 2026, 07:40

Any development news?

And where is x266? xD

Not yet. I've searched but nothing. We'll have to e-mail one of the SVT-AV1 maintainers to get insight.

As for x266, if you look up at the stars on a clear night, you might just spot it, twinkling fitfully as its SAO filter adapts to the changing scene.

Z2697

12th June 2026, 11:07

Any development news?

And where is x266? xD

x266 is a bigger joke.
Need y266 :)

hajj_3

12th June 2026, 13:16

And where is x266? xD

good joke :P

kurkosdr

12th June 2026, 13:36

x266 is a bigger joke.
Need y266 :)
Or, you know, now that the world has alternatives (see thread subject), Fraunhofer and friends can stop expecting free lunches from open-source devs (commercial or hobbyist) and further improve VVenC.

rwill

13th June 2026, 21:47

Or, you know, now that the world has alternatives (see thread subject), Fraunhofer and friends can stop expecting free lunches from open-source devs (commercial or hobbyist) and further improve VVenC.

Interesting take, given that SVT-AV1's recent psychovisual improvements are just ports of x264's psy-RD from 2008. And the people that did the port had to be quite 'active' to get the changes upstream. What got it relabeled to, --ac-bias ?

I personally would have given credit where credit is due, but then again I am just some old guy and not one of these modern developers with a blog, discord, patreon, etc.

kurkosdr

15th June 2026, 10:30

Interesting take, given that SVT-AV1's recent psychovisual improvements are just ports of x264's psy-RD from 2008. And the people that did the port had to be quite 'active' to get the changes upstream. What got it relabeled to, --ac-bias
Well, here is your answer: The devs behind x264 would rather contribute to SVT-AV1 (even if it means having to be quite 'active' to get their changes upstream) than contribute to VVenC just to help Fraunhofer and friends make more money.

When it comes to x264 and x265, hobbyist devs contributed (and contribute) because they want to get better video on their H.264 or H.265 hardware players and TVs (since H.264 is the lowest common denominator for HD and H.265 for HDR and 4K), but since every device that supports VVC also supports AV1 (with the inverse not always being true), why not contribute to the format that is not only more popular but also more closely aligns with the values of open-source?

Which leaves commercial open-source developers such as Multicoreware: Fraunhofer and friends are welcome to bet their fortunes on commercial open-source developers such as Multicoreware delivering a capable encoder for a semi-dead standard like VVC. Or they can further improve VVenC and stop expecting free lunches. Their choice.

PS: At the expense of being on-topic, it seems like AV2 has scooped ECM/H.267, so again, it looks like AOM standard will be the standard that will be both the more popular one of its generation and royalty-free. I am eager to be proven wrong in industries such as broadcast and see ECM be so good that broadcast will break compatibility with HEVC receivers (since broadcast needs all the bitrate savings it can get and doesn't particularly care about royalty-free-ness), but I highly doubt it.

birdie

17th June 2026, 11:00

The first two pieces of hardware IP (https://www.allegrodvt.com/news/pulsar-decoder-ip-support-av2-video-codec/) (1) for AV2 (https://chipsnmedia.com/en/company/news.php?boardid=news_en&mode=view&idx=50&sk=&sw=&offset=&category=) (2) decoding have been released.

What is decoding hardware Intellectual Property? It refers to a pre-designed, dedicated physical circuit (like a microchip block) used to process and decompress digital data. In computing, it typically means using specialized hardware to decode compressed video or network streams instead of forcing the main CPU to do it.

Essentially, it's a blueprint in silicon that other companies can integrate into their GPUs, APUs, SoCs, and so on, to enable you to enjoy energy-efficient hardware decoding. What does this mean in practical terms? In around 24–36 months, the first devices featuring HW AV2 decoding will be available. Could be less if the stars align ;-)

The products info pages:
* Pulsar D400 (https://www.allegrodvt.com/products-ip/pulsar-video-decoder-ip-d400-series/)
* WAVE63F1 (https://chipsnmedia.com/en/products/video-4.php)
* VC9800D (https://www.verisilicon.com/en/IPPortfolio/HantroVC9800D) (actual decoder that now supports AV2 but it's notable as well)

What's interesting is that:
World-class next-gen AV2 HW IP confirmed for future flagship devices of a major North American client
Future products are already in the pipeline. What might they be? No idea, but it could be either NVIDIA, AMD or Intel. Apple is much less likely. They normally drag their feet for years before embracing new codecs.

Z2697

17th June 2026, 11:32

So do the three giants design their own codec chip or use those SIP core(s)?

Zebulon84

17th June 2026, 13:31

… it could be either NVIDIA, AMD or Intel. Apple is much less likely … Shouldn't Qualcomm be on that list ? Their chip are in just a few computer, but on many smartphones, where "energy-efficient hardware decoding" is essential.

Z2697

17th June 2026, 13:56

Shouldn't Qualcomm be on that list ? Their chip are in just a few computer, but on many smartphones, where "energy-efficient hardware decoding" is essential.

Mediatek was earlier in the AV1 game, earliest in the smartphone beezness probably.

birdie

17th June 2026, 14:29

Shouldn't Qualcomm be on that list ? Their chip are in just a few computer, but on many smartphones, where "energy-efficient hardware decoding" is essential.

Qualcomm was reluctant to embrace AV1, that's why I "forgot" about them.

NVIDIA, Intel, and AMD all shipped consumer PC hardware AV1 decode in 2020, while Qualcomm did not add it to flagship Snapdragon phones until Snapdragon 8 Gen 2, announced November 15, 2022.

But this time around it very well could be Qualcomm. I'm 95% sure the next major Mediatek SoC architecture will support HW AV2 decoding and I don't think Qualcomm would want to be treated like a second class citizen in the game. The stakes are far too high nowadays.

And, it could be Google's Tensor as well since their RTL division is just too weak and they continue to churn subpar SoCs.

rwill

22nd June 2026, 06:09

Well, here is your answer: The devs behind x264 would rather contribute to SVT-AV1 (even if it means having to be quite 'active' to get their changes upstream) than contribute to VVenC just to help Fraunhofer and friends make more money.

I don't think x264 devs contributed to SVT-AV1 ever. I think that certain SVT-AV1 splinter group devs took what they could use from x264 source code, obfuscated it in some of their forks, and submitted it upstream to SVT-AV1 mainline. This is all well legally and within x264's GPL license but the way I see AV1 advocates advertise the 'new' features - the ancestry of the inventions seem to have been forgotten along the way. I find this rather sad.

Z2697

22nd June 2026, 21:09

I don't think x264 devs contributed to SVT-AV1 ever. I think that certain SVT-AV1 splinter group devs took what they could use from x264 source code, obfuscated it in some of their forks, and submitted it upstream to SVT-AV1 mainline. This is all well legally and within x264's GPL license but the way I see AV1 advocates advertise the 'new' features - the ancestry of the inventions seem to have been forgotten along the way. I find this rather sad.

Is this the reason why you don't work (a lot) in open source lately?

rwill

23rd June 2026, 04:15

Is this the reason why you don't work (a lot) in open source lately?

No, thats because of the corporation I work for. I would get into conflict of interest and intellectual property situations a lot when I would do open source codec development - so I just don't. I tried to give some tips and inspiration though, but there were no established developers left here that were able to pick up on this...

And as I cannot work with AV1/2 because of its license, my possible options have become quite limited anyway.

ksec

25th June 2026, 18:01

What's interesting is that:

Future products are already in the pipeline. What might they be? No idea, but it could be either NVIDIA, AMD or Intel. Apple is much less likely. They normally drag their feet for years before embracing new codecs.

The majority of SoC design for iPhone 19 is already under way and is too late to be included. You are looking at iPhone 20 at the earliest. So that is not Apple dragging their feet. And that is on the assumption the IP works perfectly in the first place.

Neither Intel or Nvidia uses Chips and Media IP for their VPU block. So I doubt that would change. More likely to be either Google or Intel. Getting their Pixel Phone to support AV2 early one. But judging how dysfunctional Google operate I doubt that would happen. So may be AMD.