AOmedia next (AV2) codec

[ksec]

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]

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]

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.

No surprises there - I'm honestly surprised that Qualcomm and Apple ever caved given how invested they were in trying to push an MPEG standard instead to no avail, but aside from them basically every other OEM had AV1 decoders in their SoCs years earlier (including all the PC GPU ODMs from 2020), and contrary to popular thought QC and Apple are far from the only players in phone town, especially in the east, and with lower end phones in the west.

[Z2697]

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

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Z2697]

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]

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]

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?
I agree, I think that going down that route is a rabbit hole. Also I think that the extension is getting more and more irrelevant for the "average joe" regardless, so it makes little sense to do it for them. And for powerusers, I would say that the understanding of container/codec is much higher today than it was 20y ago.

[kurkosdr]

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]

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]

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

[Ritsuka]

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]

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]

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]

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.
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

But even so not sure if it makes sense as it will probably look better at 1080p at that compression. But new codecs have also been less sensitive to bits/pixel, at some point maybe we do the whole abr at the same res.

[Z2697]

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".

[kurkosdr]

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]

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]

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]

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

[oibaf]

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

[Z2697]

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

[soresu]

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]

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]

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]

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]

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

[hajj_3]

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

[ksec]

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]

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]

Does someone have a binary to test?

[john33]

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]

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]

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]

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]

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]

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]

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]

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.