AOM AV1 3.6 Brings More Performance & Efficiency Optimizations

[phoronix]

Phoronix: AOM AV1 3.6 Brings More Performance & Efficiency Optimizations

Google engineers on Tuesday released AOM AV1 v3.6 as the newest version of their open-source, CPU-based AV1 encoder...

https://www.phoronix.com/news/AOM-AV1-3.6

[Danny3]

Great!

[Quackdoc]

im still more excited about the rav1e speed gains recently

[MorrisS.]

Which CPUs instructions are involved to manage Av1?

[kurkosdr]

I personally would like to see an apples-to-apples comparison with HEVC and VVC. That is, a quality comparison using the same amount of allotted time for encoding. One thing I have noticed is that VP9 and AV1 rely a lot on brute force to achieve their quality results.

Warning: Regardless of the result, you should avoid using HEVC and VVC on the web anyway. Not only are they a patent nightmare (with multiple pools demanding separate royalty payments and even charging "content fees"), but most browsers don't support them anyway. HEVC should only be used for broadcasting and UHD Blu-Rays and VVC shouldn't be used at all. That said, I would like to see the comparison anyway. Word on the grapevine is that VP9 and AV1 are using brute force as a way to compensate for the fact they can't use modern (aka patented) compression technologies. But to what extend is this true?

[Quackdoc]

I personally would like to see an apples-to-apples comparison with HEVC and VVC. That is, a quality comparison using the same amount of allotted time for encoding. One thing I have noticed is that VP9 and AV1 rely a lot on brute force to achieve their quality results.

why HEVC and not AV1? or why not all three?

Warning: Regardless of the result, you should avoid using HEVC and VVC on the web anyway. Not only are they a patent nightmare (with multiple pools demanding separate royalty payments and even charging "content fees"), but most browsers don't support them anyway. HEVC should only be used for broadcasting and UHD Blu-Rays and VVC shouldn't be used at all. That said, I would like to see the comparison anyway.

HEVC is still good for storing high fidelty local compression as all the AV1 encoders right now are lackluster in this

Word on the grapevine is that VP9 and AV1 are using brute force as a way to compensate for the fact they can't use modern (aka patented) compression technologies. But to what extend is this true?

not at all. AV1 has a lot of patents available to it, and patent pool of it was contributed by many members of AOM. but even if it was true, who would care, filesize:quality:encodespeed is all that matters in the end, and AV1 is better then HEVC, AVC, and VP9, VVC has the potential to be better then AV1, but then AV2 will be better then VVC, and ofc whatever comes after VVC will be better then AV2, but thats just how codecs work afterall.

[kurkosdr]

why HEVC and not AV1? or why not all three?

I mean take all three (AV1, HEVC, VVC) and see what quality their common implementations can produce for a given amount of time (or about the same amount of time)

Same for VP9, HEVC, VVC.

Basically see how the VPx formats really stack up against their ISO/ITU counterparts when time is taken into account.

not at all. AV1 has a lot of patents available to it, and patent pool of it was contributed by many members of AOM. but even if it was true, who would care, filesize:quality:encodespeed is all that matters in the end, and AV1 is better then HEVC, AVC, and VP9, VVC has the potential to be better then AV1, but then AV2 will be better then VVC, and ofc whatever comes after VVC will be better then AV2, but thats just how codecs work afterall.

Unfortunately, lots of "golden patents" describing essential technologies are owned by the patent holders for the ISO/ITU standards. Even basic video compression concepts had to be worked around. For example, On2 Technologies had to work around the B-frame patents by defining an "invisible" frame that can have anything written to it, so your VPx encoder can fake B-frames by writing all your B-frame information there and have a P-frame point to it (with 0,0 motion vectors and no residual and hence negligible overhead). Another issue is CABAC, which is patented, so the VPx formats have make do with good ol' Huffman arithmetic coding which is less efficient.

[kn00tcn]

i thought aom development was winding down and/or replacing most of itself with svt-av1

personally i was testing game footage encodes with ffmpeg a few months ago in an attempt to see if i can 'upgrade' past x264 to either increase quality or reduce filesize

aom was painfully slow without usable quality, rav1e was very disappointing with similar issues, only svt produced acceptable quality at acceptable time, for some reason x265 was a disaster with half or quarter speed at worse quality

x264 target:

-c:v libx264 -preset slower -crf 20 -deblock -1:-1 -tune film

similar av1:

-c:v libsvtav1 -crf 29 -preset 6 -svtav1-params tune=0

this where i've settled for now, lower preset value takes longer in exchange for a tiny bit more texture detail in dark or blurred areas... but i havent gained anything, longer encode time, losing hw decoding, same filesize, similar quality

av1 is amazing at excessively low bitrates though (like pushing it down to 500kbit from the high quality 10mbit), you can even see interesting artifacts showing you how it's saving bitrate where different parts of the image are running at different framerates

at least on jpeg-xl i have decently smaller screenshots with much higher gradient quality, plus most of the obvious sparkling artifacts of old jpg are gone (4:4:4 colors at all times, before jpg97 or jpg96, upgraded to jxl98, jxl100 is always smaller than png sometimes smaller than webp100, lossless conversion of jpg to jxl including those sparkles is still smaller filesize, very happy with jxl, webp is garbage that cant do lossy 4:4:4)

Which CPUs instructions are involved to manage Av1?

that depends on the library being used, there are multiple encoders (aom, svt-av1, rav1e, ...) and multiple decoders (dav1d, ...)

[Quackdoc]

i thought aom development was winding down and/or replacing most of itself with svt-av1

personally i was testing game footage encodes with ffmpeg a few months ago in an attempt to see if i can 'upgrade' past x264 to either increase quality or reduce filesize

aom was painfully slow without usable quality, rav1e was very disappointing with similar issues, only svt produced acceptable quality at acceptable time, for some reason x265 was a disaster with half or quarter speed at worse quality

x264 target:

-c:v libx264 -preset slower -crf 20 -deblock -1:-1 -tune film

similar av1:

-c:v libsvtav1 -crf 29 -preset 6 -svtav1-params tune=0

this where i've settled for now, lower preset value takes longer in exchange for a tiny bit more texture detail in dark or blurred areas... but i havent gained anything, longer encode time, losing hw decoding, same filesize, similar quality

av1 is amazing at excessively low bitrates though (like pushing it down to 500kbit from the high quality 10mbit), you can even see interesting artifacts showing you how it's saving bitrate where different parts of the image are running at different framerates

at least on jpeg-xl i have decently smaller screenshots with much higher gradient quality, plus most of the obvious sparkling artifacts of old jpg are gone (4:4:4 colors at all times, before jpg97 or jpg96, upgraded to jxl98, jxl100 is always smaller than png sometimes smaller than webp100, lossless conversion of jpg to jxl including those sparkles is still smaller filesize, very happy with jxl, webp is garbage that cant do lossy 4:4:4)




that depends on the library being used, there are multiple encoders (aom, svt-av1, rav1e, ...) and multiple decoders (dav1d, ...)

not a chance on aom's av1 dying down, SVT-AV1 still has a low quality ceiling, no support for 4:2:2+ aomenc is faster on arm devices. so for higher fidelity encodes, arm hardware and when you want the absolute best quality:filesize aomenc right now is king. SVT-AV1 is good for fast encodes, but thats it

[kurkosdr]

personally i was testing game footage encodes with ffmpeg a few months ago in an attempt to see if i can 'upgrade' past x264 to either increase quality or reduce filesize

aom was painfully slow without usable quality, rav1e was very disappointing with similar issues, only svt produced acceptable quality at acceptable time, for some reason x265 was a disaster with half or quarter speed at worse quality

x264 target:

-c:v libx264 -preset slower -crf 20 -deblock -1:-1 -tune film

similar av1:

-c:v libsvtav1 -crf 29 -preset 6 -svtav1-params tune=0

this where i've settled for now, lower preset value takes longer in exchange for a tiny bit more texture detail in dark or blurred areas... but i havent gained anything, longer encode time, losing hw decoding, same filesize, similar quality

av1 is amazing at excessively low bitrates though (like pushing it down to 500kbit from the high quality 10mbit), you can even see interesting artifacts showing you how it's saving bitrate where different parts of the image are running at different framerates

VP9 and AV1 encoders should not be benchmarked against AVC encoders such as x264. The whole point of formats like VP9 and AV1, and also HEVC and VVC, is to trade encoding time for bitrate savings.

VP9 is of the same "generation" as HEVC and AV1 is of the same "generation" as VVC, but I would like to see VP9 benchmarked against HEVC and VVC and AV1 also benchmarked against HEVC and VVC.