Alliance for Open Media codecs

[birdie]

Eh, for streamers, not for those who actually watch those streams, which is my use case... :(
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.

[FranceBB]

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.

Ah, so it wasn't just me and my eyes. Thanks for confirming.
It's a shame, really... :(

[benwaggoner]

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.

[birdie]

Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.

That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.

[benwaggoner]

That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.
VP9 was mostly on YouTube, where they did single-threaded encoding of short chunks distributed on otherwise idle Google cloud instances. That mode is all about throughput per watt, which single-threaded encoding is best at. Live is all about throughput per minute, so multithreading is really important.

VP9 was particularly poor for multithreading as frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured. Shared entropy coding context across frames also limited decoder threading. VP9 was definitely a codec designed to run on a fast x86-64 core without a lot of consideration for multithreaded hardware or software implementations. AV1 is somewhat better, but is still more complex to decode than even VVC.

HEVC's Wavefront Parallel Processing is great and elegant, allowing for one thread per 64 pixels tall of the video. WPP yields better compression efficiency than slices, tiles, and frame threading. The more traditional IPBb reference frame hierarchy of H.264 and HEVC makes for more straightforward frame threading, although there is always some risk of quality regressions.
Some frame threading is feasible in AV1 doing tricks with golden frames. SVT-AV1 is a good demonstration of an AV1 encoder that can do a lot of threading (although quality isn't great). It'd be interesting to compare SVT-HEVC and SVT-AV1's parallelization.

Fragment/GOP level threading has challenges due to higher latency and making sure VBV state is compliant across fragment boundaries. But the encoders are well optimized for that as that's YouTube's primary encoding model.

I hope AV2 focuses more on architectural support for highly parallelized encoding and decoding.

[Beelzebubu]

AV1 is also very hard to parallelize

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

[Beelzebubu]

frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured.

It's just how big the deblock filter is in VP9: writing 7 pixels on each side, making the luma delay 7+64 lines, but because downsampled chroma has the same filter length, it has the same delay (i.e. 7+32 lines in memory), the ultimate delay is 14+64=80 lines. In AV1, the line buffer is 8+128=136 (luma) lines (or 4+64 for downsampled chroma). Note that this is not less than VP9. HEVC is only a few lines better than VP9 in this respect, and VVC is no different from AV1.

Shared entropy coding context across frames also limited decoder threading.

... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.

[birdie]

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

And SVT-AV1 is nowhere near close to libaom (almost single-threaded) in terms of quality. Right.

[benwaggoner]

... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.
IIRC it made the decoders too complex, and added a lot of latency for random access. It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).

[takla]

Eh, for streamers, not for those who actually watch those streams, which is my use case... :(
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...

I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is. I understand that they do this for bandwidth savings, obviously, but they could simply have strict bitrate requirements in place and probe the stream...

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.

You can pick 1 of 3 speed settings in the youtube streamer dashboard. The setting with the highest delay offers the 'best' image quality. By default it is set to low latency, which is worse but most people don't change it.

[RanmaCanada]

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

SVT-AV1 is garbage. No matter how many times I try to use anything but, I can't get it to work with multi-threading and it just uses 1 core (SVT-AV1 is the only encoder that uses all my cores, for clarity). This shows just how broken the codec is. I've argued with bluesword a lot over this and the only answers I ever get is "use these" never "this is why it's a single threaded encoder".

There is far too much gatekeeping on the documentation, and far too much "why isn't this working".

If they really want this to take over HEVC and in the future VVC, things need to fixed and addressed. Blindly defending it without addressing it's massive shortcomings and serious problems won't make it any better.

[hajj_3]

I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is.
recently youtube has been testing a high bitrate 1080p setting option.

[Beelzebubu]

IIRC it made the decoders too complex, and added a lot of latency for random access.
[..]
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).

Ah, yes! The random access argument is interesting, and I'd very much agree with the second sentence. I've used the following argument before: I think we'd both agree entropy dependency vs. seeking is essentially an identical problem to actual pixel dependencies from reference structures vs. seeking. The fact that MPEG allows pixel dependencies in complex frame ordering structures (a.k.a. inter frame coding) and knows how to seek bit-exactly and efficiently in it demonstrates how easily the entropy can be solved, too. Because: it is the same problem.

Maybe part of the problem is that MPEG folks tend to like formalizing rules for this sort of stuff and picking at theoretical inconsistencies. I personally find that quite uninteresting once the problem itself is already solved.

It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.

I don't believe it's quite that simple. Whether content is "simple" or "hard", entropy is typically quite correlated over time. You're right that after entropy convergence, you're still spending bits on the actual signal, but at least entropy is optimal coming in to each frame. Therefore, you'll get gains across the board.

To get more practical, I compared --frame-parallel=0/1 encodes at -q 30/40/50/60 to obtain BDRATE-PSNR differences, and observed a -2.5% average difference on the cif clipset (https://media.xiph.org/video/derf/) from Xiph. These were only partially complexity-ordered. Husky, for example, gained "only" -1.0% on average, but football, soccer, foreman & harbour each gained -2.5%. Same on the easy end: clips like akiyo an students are "only" -2.0% each, whereas news and bowing are -2.5%. The best clips (around -4.0% each) are bridge_far, crew, sign_irene and highway, which are by no means the easiest clips in the set. I also checked for "bitrate" bias: gains are quite evenly distributed across all -q values for each clip.

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.

[birdie]

recently youtube has been testing a high bitrate 1080p setting option.

Lossy (re-)encoding always deceases quality. Period. Are you new to audio/video encoding?

[dapperdan]

https://www.anandtech.com/show/18805/amd-announces-alveo-ma35d-media-accelerator-av1-video-encode-at-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

[benwaggoner]

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.
Yes, I concur interframe entropy coding, properly structured, is definitely of value. I was trying to recapitulate the original MPEG thinking as I recalled it, not justify it.

[hajj_3]

https://www.anandtech.com/show/18805/amd-announces-alveo-ma35d-media-accelerator-av1-video-encode-at-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

quality sounds great:

https://i.imgur.com/KVzQFmP.png

[benwaggoner]

quality sounds great:
It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes.
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

[Blue_MiSfit]

Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

QFT. I've been impressed with how much better NVENV AV1 is relative to NVENC HEVC, but it's still maybe only close to fast x265 presets. Great for what it is, but that's NOT the same as ~matching x265 slow at 1W per stream. If that's to be believed it's bonkers good. Fabulous for live ABR encoding!

I could see this being popular in the cloud IaaS providers soon. It would _smoke_ the older NVIDIA hardware that's usually available there e.g. Ampere in AWS g5 instances.

[benwaggoner]

Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.

[Ayumu111]

Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.
I concur with Ben that high-quality adaptive bitrate (ABR) live streaming requires powerful hardware to attain high-quality compression. As codec standards and standards become increasingly complex, hardware encoders may find it difficult to keep up. Software-based streaming solutions that leverage the power of fast core processors will continue to be the preferred method for high-quality live streaming.

[Spyros]

The AOMedia Research Workshop Europe 2023 will take place in a few days (June 19th), in Ghent, Belgium.

The conference program is in the image below, more details about each presentation can be found at the official website (https://sites.google.com/view/qomex2023/workshops/aomedia-research-workshop-europe-2023).

The focus seems to be on AV2 and a retrospective of AV1 development and the technologies that were used in it.

https://i.imgur.com/Fgd9mdY.png

[nisha_gomes]

It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes. (https://aeroapp.net/fmwhatsapp-download-apk/)
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.


The progress in comparing AV1 with highly efficient encoding methods like H.264 Baseline VeryFast and x265 slow is impressive, especially considering the historical challenges in achieving high-quality live AV1 encoding.

[LigH]

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 13.1.0)

AOM v3.6.1-843-g93ca91b96 (https://www.mediafire.com/file/c9umcoe48zwg4ni/aom_v3.6.1-843-g93ca91b96.7z/file)

rav1e 0.6.1 p20230711-1-g2447fcc (https://www.mediafire.com/file/flmjlxalvwwbn6n/rav1e_0.6.1_p20230711-1-g2447fcc.7z/file)

dav1d 1.2.1-43-g9278a14 (https://www.mediafire.com/file/iw9rxno50123621/dav1d_1.2.1-43-g9278a14.7z/file)

SVT-AV1 v1.6.0-2-gba18204e (https://www.mediafire.com/file/qthhdy89die1rv1/SVT-AV1_v1.6.0-2-gba18204e.7z/file)

avif 0.11.1-41ed914 (https://www.mediafire.com/file/jgfpe95o0v7zvdi/avif_0.11.1-41ed914.7z/file)
dav1d [dec]:1.2.1-43-g9278a14, aom [enc/dec]:3.6.1-842-gff3c4c8a6, rav1e [enc]:0.6.1 (p20230711-1-g2447fcc)

[mzso]

Hi!
Is Youtube still the only notable user of AV1 nowadays?

[butterw2]

Just like VP9 ?

[mzso]

Just like VP9 ?

Not sure how that's relevant.

[benwaggoner]

Not sure how that's relevant.
It is historically relevant, as YouTube has been the primary user and driver of VP8, 9, and 10/AV1. VP8 and VP9 were really limited by the reference/sample encoder being highly tuned for YouTube scenarios and not well suited for for other use cases, like highly parallelized encoding of premium content. That caused some chicken/egg problems that prevented VP9 from getting encoders nearly as refined as those for H.264 and HEVC. I don't think VP9 as a bitstream could have outperformed HEVC in real-world applications, but VP9 encoders weren't able to capture as much of the potential of the bitstream as H.264 and HEVC encoders have, as the market for those commercial encoders is orders of magnitude higher.

For example, VP8/9 had very serialized decoding and limited on encoding. Which was fine for YouTube, which encodes in little slices of times on lots of different edge compute nodes as available. But premium content where time-to-publish is essential and encoding 3x more slowly to reduce bitrate by 10% is excellent ROI, it's a big limitation. And when secure DRM is a hard requirement and dropped frames cause cancelled subscriptions or purchase/rental refunds, having reliably fast decoders, preferably HW, are much more important.

While user generated content gets a lot of eyeball hours, the economic value of improved quality and speed/efficiency tradeoffs are very different, and the $/hour invested are a tiny fraction of what premium content gets.

AV1 has a much healthier ecosystem than any prior VPx version (going back to VP3 even), with more and better encoders available. So it's a compare and contrast.

[CodecWar]

Hello! Today, I bring some exciting news about the AV2 codec developed by the AVM team. As many of you might be aware, AV2 is the successor to AV1 and aims to provide even better video compression and quality. In this post, I'll be discussing the recent advancements in AV2 and how it compares to its predecessor, AV1.

Active Development of AV2 Codec:
The AVM team has been hard at work, continuously refining the AV2 codec to enhance its performance. Over the last couple of years, they have released several research tags to showcase their progress. In August 2021, the research2 tag was unveiled, followed by research3 in May 2022, and research4 in April 2023.

Comparative Analysis on AOM AV2 CTC Streaming Classes:
Recently, a comprehensive report was published that compared the performance of these three AV2 implementations on AOM AV2 CTC Streaming classes, namely A5, A4, A3, and A2, focusing on resolutions up to FullHD. The objective was to evaluate the quality metrics of PSNR (Peak Signal-to-Noise Ratio), VMAF (Video Multi-Method Assessment Fusion), and SSIM (Structural Similarity Index) for the different research releases.

Steady Quality Improvements:
The results of the study were nothing short of impressive. Across all quality metrics, there was a consistent improvement as the research progressed from version 2 to version 4. For example, the PSNR: Y (luma) with BD-Rate data aggregation showed a remarkable 8.76% improvement between research3 and research4. This demonstrates the commitment of the AVM team to refining their codec and pushing the boundaries of video compression technology.

Spread and Variance:
It's important to note that while the best and worst results also improved with each iteration, the spread and variance between different video streams increased. This suggests that the AV2 codec is becoming more specialized in handling certain types of video content optimally.

Conclusions from the Study:
Based on the findings of this study, some significant conclusions were drawn:

On average, the AOM_post-AV1 (research 3 released in 2022 ) codec showed an 8.76% improvement over the AOM_post-AV1(research 2 released in 2021) reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.
In summary, the AV2 codec is showing immense promise and dedication from the AVM team. As the development progresses, it is evident that AV2 is significantly surpassing its predecessor, AV1, in terms of video quality and compression efficiency. However, with the increasing specialization, the codec might perform differently depending on the content being encoded.

It's an exciting time for video compression enthusiasts, and we can't wait to see how AV2 evolves further. Feel free to share your thoughts and insights in the comments below! Let's discuss the future of video codecs together.

Source: https://codecwar.com/compare/av2-research-evolution

[benwaggoner]

If all we are seeing on net is a 15.15% efficiency improvement, that is very overwhelming. A new codec needs a plausible path to around a 100% efficiency improvement (same quality, half the bitrate) to displace a prior one, or needs to add a substantial and compelling new feature (like broadcast-grade interlaced SD and HD video for MPEG-2, HDR for HEVC). 15% over AV1 is still a lot worse compared to VVC, which will have HW decoders shipping in products by end of 2023. It's also lower than the delta from VVC to current post-VVC test implementations from MPEG.

[hajj_3]

If all we are seeing on net is a 15.15% efficiency improvement, that is very overwhelming.

*underwhelming. AV2 isn't being ratified right now, so i wouldn't pay much attention that it is only 15% better. In a year i'm sure it will be more than that.

[Beelzebubu]

On average, the AOM_post-AV1 codec showed an 8.76% improvement over the AOM_post-AV1 reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 codec outperformed the AOM_post-AV1 reference codec by an impressive 15.15%.

So X outperformed X by 8.76% and 15.15%? I assume some "AOM_post-AV1" labels above are meant to be something else?

[CodecWar]

So X outperformed X by 8.76% and 15.15%? I assume some "AOM_post-AV1" labels above are meant to be something else?

I've updated the post to make it clear that it compares the same codec in 3 releases :
research2 Aug21,
research3 - May22,
research 4 - Apr22

[benwaggoner]

*underwhelming. AV2 isn't being ratified right now, so i wouldn't pay much attention that it is only 15% better. In a year i'm sure it will be more than that.
Yeah, no one would release a new codec with that small a delta. Us graybeards remembered what happened when MPEG-4 pt 2 came out with only maybe 20-30% more efficiency than MPEG-2. Just not worth the hassle.

Hence H.264, which was a pretty ground-up rethink of how to encode video that could deliver on 100% efficiency improvements.

[benwaggoner]

I've updated the post to make it clear that it compares the same codec in 3 releases :
research2 Aug21,
research3 - May22,
research 4 - Apr22
Thank you for the clarification.

I'm still surprised that the rate of improvement isn't higher, though. Lots of H.264 patents have expired, and thus don't have to be worked around, plus years more of academic research and work on the specific codec.

I am guessing that the ML stuff isn't refined enough to deliver material benefits yet. That's probably the make or break for AV2. I find myself atypically unsure of how big a real-world difference that could make. We could well wind up still not knowing even at release, as there are SO many new ways an encoder can be tuned and can optimize a bitstream with ML as an option. Incorporating ML model overhead into rate control alone is a chewy interesting challenge.

[hajj_3]

avif 1.0.0 has been released: https://github.com/AOMediaCodec/libavif/releases/tag/v1.0.0

[ksec]

Conclusions from the Study:
Based on the findings of this study, some significant conclusions were drawn:

On average, the AOM_post-AV1 (research 3 released in 2022 ) codec showed an 8.76% improvement over the AOM_post-AV1(research 2 released in 2021) reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.
In summary, the AV2 codec is showing immense promise and dedication from the AVM team. As the development progresses, it is evident that AV2 is significantly surpassing its predecessor, AV1, in terms of video quality and compression efficiency. However, with the increasing specialization, the codec might perform differently depending on the content being encoded.

Source: https://codecwar.com/compare/av2-research-evolution

This doesn't make any sense.

the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.

So R4 outperform R3 by 15.15%. Except your link below shown

AOM_post-AV1 codec is better than AOM_post-AV1 reference codec by 15.15%, in average on all video streams.

The Reference is R2. i.e R4 is 15.15% better than R*2*.

Improvement in percentage also doesn't make sense. It is BD-Rate ( Which the report actually suggest ). i.e Reduction. ( Which is why I assume benwaggoner was confused and mentioned 100% improvement as in efficiency as 50% BD-Rate )

Now if I remember correctly, R2 is something like 10% BD-Rate on AV1. So that is 15.5% on top of 10%, multiply to less than 25%.

Which if I have to guess AV2 at R4 isn't even at VVC level. On the other hand, latest H.267 development is already at 30%+ on top of VVC.

Did I mention AV2 was suppose to be out in ( *cough* ) 2020.

So yes, I do think it is quite underwhelming. Previously Google was so fixated that next gen video codec being ML based and doesn't seems to offer any alternative. I wonder if R1- R4 is still ML based.

[Gravitator]

On the other hand, latest H.267 development is already at 30%+ on top of VVC.
Привет!
Will they go above blocks 128?

[benwaggoner]

Which is why I assume benwaggoner was confused and mentioned 100% improvement as in efficiency as 50% BD-Rate )
Yeah, this is a place where we could be crisper in the industry on the terminology. A reduction in bitrate is the reciprocal of an improvement in efficiency. So, a 100% improvement in compression efficiency IS a 50% reduction in bitrate. A 300% improvement in compression efficiency is a 75% reduction in bitrate. We could save some real confusion if we clearly specified which we meant when we are talking % better.

So yes, I do think it is quite underwhelming. Previously Google was so fixated that next gen video codec being ML based and doesn't seems to offer any alternative. I wonder if R1- R4 is still ML based.
I gather that there was some demonstration of value in some ML tool in the latest tests, but shy of 2%. AV2 doesn't seem to have any big organizing principle for how to make a big jump in compression efficiency, or any novel tools that would really have a big impact.

I'd hoped that the expiration of so many H.264 and other patents since AV1 would allow the use of tools AOM had wanted to use in AV1 but couldn't. It doesn't seem to have been the case. Perhaps the VPx core structure to avoid patents was so far off from the MPEG codec development process that tools weren't easily reusable?

[hajj_3]

libaom 3.7 is out: https://aomedia.googlesource.com/aom/+/refs/tags/v3.7.0

[Boulder]

Question regarding --chroma sample position: is it 2 for HDR?

Description of the parameter in the help text: "The chroma sample position when chroma 4:2:0 is signaled: unknown, vertical, colocated"

[benwaggoner]

Question regarding --chroma sample position: is it 2 for HDR?

Description of the parameter in the help text: "The chroma sample position when chroma 4:2:0 is signaled: unknown, vertical, colocated"

It is 2 for UHD HDR Blu-ray. Although I'm skeptical that end-to-end support is reliably implemented; a number of devices ignore the metadata and assume it is 0 like everything was forever. At 2160p getting it wrong is nigh invisible. I do worry about a 360p OTT HDR stream, though, as a half pixel is a 720p pixel.

[oibaf]

libaom 3.8.0 was released:

2023-11-30 v3.8.0
This release includes new codec interfaces, compression efficiency and
perceptual improvements, speedup and memory optimizations and many bug
fixes. This release is ABI compatible with the last release.
- New Features
* New codec controls:
* AV1E_SET_MAX_CONSEC_FRAME_DROP_CBR: Set the maximum number of
consecutive frame drops allowed for the frame dropper in 1 pass
CBR mode.
* Run-time CPU feature detection for all Arm platforms:
CRC, DotProd, I8MM and SVE CPU feature presence is detected at run
time and code paths making use of these features are selected
dynamically. These code paths provide meaningful performance gains
for standard bitdepth RTC and VoD encoding: up to 10% and 20%
respectively, over the Armv8.0-A baseline build.
* RTC: Frame-dropper support added to the rate control library.
* RTC Rate control improvements for low bitrate and for SVC.
- Compression Efficiency Improvements
* Improved accuracy of cost estimation for loop restoration and
global motion.
* Improved selection of loop restoration unit size - full search up
to (non-realtime) speed 2, retuned static selection at higher
speeds.
* RTC Screen content mode: 3-5% bdrate gains across speeds 7 - 10.
* Good-quality mode: 0.2 - 0.5% bdrate gains across speeds 1 - 4.
- Perceptual Quality Improvements
* RTC Screen: Improved visual quality for scrolling.
* RTC: Improved color quality for both screen and video mode.
- Speedup and Memory Optimizations
* Good-quality, single-thread encoder speedups:
o 15% improvement for speed 5.
o 12% improvement for speed 6.
* Arm standard bitdepth VoD (--good):
o 8% speedup for speeds 0 and 1.
o 20% speedup for speed 2.
o 27% speedup for speed 3.
o 30% speedup for speed 4.
o 38% speedup for speeds 5 and 6.
* Arm high bitdepth VoD (--good):
o 206% speedup for speeds 0 and 1.
o 180% speedup for speed 2.
o 51% speedup for speeds 3 and 4.
o 68% speedup for speed 5.
o 72% speedup for speed 6.
* RTC Screen content: 2-6% speedup across speeds 7-10.
* RTC: 2-3% speedup for temporal layers.
* RTC: Speedups to reference scaling in nonrd pickmode.
* Good-quality mode: Simplified global motion estimation, saving
~1200 lines of code and 1KB of tables while improving quality.
- Bug Fixes
* Fixes to improve libaom stability in case of memory allocation
failures.
* Fixes to SIMD functions (x86 AVX2/SSE2 and ARM Neon).
* b/310457427, b/310766628: Bug fixes to only use rec_sse in CBR
mode.

[oibaf]

Also, post 3.8.0: https://aomedia.googlesource.com/aom/+/0152ba993998cdb45b88d17622b898add3dca65b

rtc: Speed 11 for video mode, for resoln < 720p.

This is a very aggressive fast speed setting for
video in real-time mode (RTC).

-force single reference
-aggressive cdef skip
-selective cdf_update
-turn off motion interpolation filter search
-use only DC for intra-modes
-increase thresholds for source_sad and transform
skipping test
-faster partitioning - fixed per superblock

bdrate and IC change from speed 10 rtc_derf:
~29% IC speedup and ~26% bdrate loss

To be tuned/adjusted further.

[oibaf]

SVT-AV1 1.8.0 was released:

[1.8.0] - 2023-12-11

Encoder
Improve the tradeoffs for the random access mode across presets:
Speedup CRF presets M6 to M0 by 17-53% while maintaining similar quality levels
Re-adjust CRF presets M7 to M13 for better quality with BD-rate gains ranging from 1-4%
Improve the quality and speed of the 1-pass VBR mode
Improve Multi Pass VBR algorithm for better quality with BD-rate gains of ~3% on average
More details on the per preset improvements can be found in MR !2143
Add API allowing to update bitrate / CRF and Key_frame placement during the encoding session for CBR lowdelay mode and CRF Random Access mode
ARM Neon SIMD optimizations for most critical kernels allowing for a 4.5-8x fps speedup vs the c implementation
Cleanup and bug fixes and documentation

Various cleanups and functional bug fixes
Update the documentation for preset options and individual features

[GTPVHD]

https://www.intel.com/content/www/us/en/newsroom/news/core-ultra-client-computing-news-1.html

Intel Core Ultra Meteor Lake officially launched, Intel's first processor family with AV1 hardware encoder.

[Yups]

https://www.intel.com/content/www/us/en/newsroom/news/core-ultra-client-computing-news-1.html

Intel Core Ultra Meteor Lake officially launched, Intel's first processor family with AV1 hardware encoder.


Here a comparison to Phoenix: https://youtu.be/4sQMR3cQtCU?t=690

[hajj_3]

mozilla has removed AV1 support from firefox 121 on windows and now requires you to install the Microsoft AV1 Video Extension from microsoft store instead: https://www.mozilla.org/en-US/firefox/121.0/releasenotes/

This is likely due to avanci demanding royalties from AV1 streaming.

[birdie]

mozilla has removed AV1 support from firefox 121 on windows and now requires you to install the Microsoft AV1 Video Extension from microsoft store instead: https://www.mozilla.org/en-US/firefox/121.0/releasenotes/

This is likely due to avanci demanding royalties from AV1 streaming.

They didn't remove anything.

AV1 software decoding is still there. The extension is required for HW decoding. Windows LTSC doesn't have the extension installed by default and millions of people use this version of Windows because it's the version to use. Unfortunately MS for some reasons decided not to include HW video decoding with this Windows SKU.

[hajj_3]

Microsoft Edge 121 Beta has enabled AVIF decoding support by default.