AV1 Codec Library libaom v3.2 Brings More Performance Optimizations

[Bella0450]

From my own tests, the video coding and intra-coding improvements have made it so that presets aside from RT have the same objective scores and subjective quality has actually improved nicely.

[piotrj3]

I have been working with video for as long as I have been using Linux, which goes back to 1998.

If you visit the VideoHelp forums you will find tons of posts by me with hundreds of encoding tests, done using x264, x265, SVT-AV1, SVT-HEVC, SVT-VP9, CUDA, Nvenc H264, Nvenc H265, QSV H264/H265 on both Linux and Windows, QSV via VAAPI on Linux including testing hardware H264/H265/VP8/VP9 encoding and hardware accelerated filters.

I don't know which AV1 encoder you have tried, but in my tests, and those of other I have seen, both VP9 and x265 beat x264 easily and AV1 beats them all.

Quantization settings are very error prone and quantization setting for one codec are totally diffrent for another.

You need to calculate values like PSNR or SSIM and compare them. There is however one more trick there because PSNR/SSIM requires codec to disable "psycho-visual" quality upgrades, codecs generally have all those settings for sake of proper comparison.

By my own tests done around ~~ 1 year ago, AV1 achieves at same bitrate better PSNR/SSIM values then X265, and X265 achieves better values then X264. However:
- you have to tweak profile - by example RTX30XX serie, can hardware decode X264 high up to profile 5.1, but only main profile from X265 and AV1, so setting X264 to high is more fair,
- you have to set realistic encoding quality scenario - eg. encoding takes similar time on all codecs without overly going far on settings, Placebo is literally useless, anything below "slower" for x264/x265 is pointless as codec benefits barerly for doing a ton more work,
- generally try to encode for 10bit, 8 bit is simply worse, even at low bitrates,
- set tune for PSNR/SSIM OR disable all psychovisual encoding settings,
- make sure you use same chroma (i420 or i422 or i444, generally most common is i420)

Now does AV1 always win - well not always. On very high speed settings, SVT-AV1 can still lose to high complexity NVENC in quality preset that simply is so fast that dropping settings on AV1 makes image worse for still slower speed of encoding, but that is simply beauty of Turing Nvidia encoder.

Also certain images work better for one codec or another, eg. Anime can be encoded extremly well in AV1, people for joke encoded entire anime episode (24mins long) into 8MB AV1 file and suprisngly image was quite coherent.

[flashmozzg]

Michael

Either the graphs are mislabeled or something is very wrong with the test systems, specifically the EPYC one. According to your graphs, a Ryzen 9 5900X (12C/24T) beats an Epyc 7742 (64C/128T) by 40% to 100%!

I'm sorry but these results can not be trusted, AV1 scales very well, there has to be some misconfiguration in the EPYC system.

AOM is not really multi-threaded. If you have several videos that you want to encode at the same time, you'll do that faster on EPYC.

[sophisticles]

Have you actually tried encoding any thing and then looked at it carefully? If not try it. The common recomendation is to use -crf 20 but when I compare that to even the defaults for x264 it has lost a LOT of detail. I have to get down to -crf 8 before they are equivalent. I suspect a lot of people talking about how great the compression with AV1 is ether don't actually care about quality and are looking for the most squeeze because they are going to watch on their cell phone or don't know what to look for.

I have been working with video for as long as I have been using Linux, which goes back to 1998.

If you visit the VideoHelp forums you will find tons of posts by me with hundreds of encoding tests, done using x264, x265, SVT-AV1, SVT-HEVC, SVT-VP9, CUDA, Nvenc H264, Nvenc H265, QSV H264/H265 on both Linux and Windows, QSV via VAAPI on Linux including testing hardware H264/H265/VP8/VP9 encoding and hardware accelerated filters.

I don't know which AV1 encoder you have tried, but in my tests, and those of other I have seen, both VP9 and x265 beat x264 easily and AV1 beats them all.

[sophisticles]

Does libaom actually scale that well, or just SVT-AV1? They're two completely different implementations.

If you look at the benchmarks closely, the Ryzen 9 5900X (12C/24T) is 2 to 3 times faster than the Ryzen 5 5500U (6C/12T), since the 5900X has a base clock of 3.7ghz (4.8ghz boost) and the 5500U has a base clock of 2.1ghz (4ghz boost), I would say that the performance cap is right on the money.

But the Ryzen 9 5900X (12C/24T) beats an Epyc 7742 (64C/128T) by 40% to 100%, and the Epyc 7742 has a base clock of 2.25ghz with a boost of 3.4ghz.

So let's do some half-baked performance predictions:

Ryzen 9 5900X - 12C*3.7ghz + 12C/2*3.7ghz = 66.6ghz of base processing power
Epyc 7742 - 64C*2.25ghz + 64C/2*2.25ghz = 216ghz of base processing power
Ryzen 5 5500U - 6C*2.1ghz + 6C/2*2.1ghz = 18.9ghz of base processing power

66.6 / 18.9 = 3.5

Which is close to the performance difference we are seeing between Ryzen 9 5900X and Ryzen 5 5500U, which means not only is this software not scaling but the Ryzens are even boosting up for any significant length of time. If the Epyc was boosting then at the very least it would be coming close to the 5900X but it's getting blown away.

I still think there's something wrong, possibly with the governor the systems are using.

[MadeUpName]

You are doing something very wrong, x265 and vp9 have both been proven much better than x264 and vp9 has been shown to be superior than x265 at resolutions above 1080p.

Since AV1 is the continuation of vp10, which was supposed to replace vp9m there is no way that you "need larger AV1 files to get the same quality as x264".

Have you actually tried encoding any thing and then looked at it carefully? If not try it. The common recomendation is to use -crf 20 but when I compare that to even the defaults for x264 it has lost a LOT of detail. I have to get down to -crf 8 before they are equivalent. I suspect a lot of people talking about how great the compression with AV1 is ether don't actually care about quality and are looking for the most squeeze because they are going to watch on their cell phone or don't know what to look for.

[quikee]

I must say that these benchmarks aren't really helpful without also checking the quality as the developers are still tuning the speed levels. So they might disable some expensive coding tool or do a less exhaustive search at a certain speed level and we would see a performance increase but what we wouldn't see is that the quality also dropped. Similarly they could enable some coding tool at a certain level and we would see a performance regression in benchmarks, but there would also be a quality increase, which we wouldn't see...

[quikee]

Does libaom actually scale that well, or just SVT-AV1? They're two completely different implementations.

No, libaom and libvpx before are known to be rather bad at multi-threading.

[quaz0r]

I have tested SVT-AV1 extensively against both x264 and x265 and SVT-AV1 beats them handily

interesting, thanks

[smitty3268]

I'm sorry but these results can not be trusted, AV1 scales very well, there has to be some misconfiguration in the EPYC system.

Does libaom actually scale that well, or just SVT-AV1? They're two completely different implementations.

I think libaom hasn't been that well tuned and may be targeted more towards a youtube like service that does 1 thread per video and extracts parallelism through having tons of videos, rather than a workstation oriented process that tries to do 1 video as fast as possible.

But i haven't followed av1 codecs that closely, so maybe you are right.