AOmedia next (AV2) codec

[birdie]

Some news about AV2: https://ottverse.com/av2-video-codec-evaluation/

[benwaggoner]

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.

[BlueLane]

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]

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]

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]

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]

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]

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]

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.

[Gravitator]

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]

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]

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]

Looks like it's being quite actively worked on:

https://gitlab.com/AOMediaCodec/avm

[Tommy Carrot]

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]

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]

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]

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

[birdie]

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]

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

[Jamaika]

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

[Tommy Carrot]

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]

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

[CodecWar]

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]

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]

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.

[benwaggoner]

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]

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.

[Jamaika]

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]

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]

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

You should report it here: https://gitlab.com/AOMediaCodec/avm/-/issues

[Jamaika]

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?

[hajj_3]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Jamaika]

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

[benwaggoner]

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]

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]

AOM is anything but Open.

What makes you think like this?

[GeoffreyA]

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]

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]

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]

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.

It took me one hour and 15 minutes to encode three seconds, so I gave up hope :)