SVT-AV1 0.8 Brings More AVX2/AVX-512 Optimizations, Multi-Threaded Decode Support

[phoronix]

Phoronix: SVT-AV1 0.8 Brings More AVX2/AVX-512 Optimizations, Multi-Threaded Decode Support

Intel's Scalable Video Technology SVT-AV1 video encoder/decoder for AV1 content has already been the speediest of the various solutions we have tried, but now a new release is available and it looks to be even faster for CPU-based AV1 video encode/decode...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-AV1-0.8-Released

[dwagner]

Video codec speed benchmarks are futile if not accompanied by comparison of quality at different bit rates.
Please, don't just measure speed.

[AndyChow]

Video codec speed benchmarks are futile if not accompanied by comparison of quality at different bit rates.
Please, don't just measure speed.

I don't even know how you could compare quality. In one report I saw (MSU video codecs comparison 2019), you have the BSQ-rate which is an objective method, but does not match subjective ratings.

From what I feel, pretty much any video which is transcoded, regardless of encoder used or parameters (even "placebo", which creates a file 10x+ the size of the original) look horrible, and pretty much any initial encoding with adequate parameters looks pretty good. I use hardware accelerated encoding when recording desktop tutorials (NVENC), and I can't tell the difference between that and lossless recording which is later encoded. I know software encoding should give better results, but I don't experience this in reality.

If there is some good automated way to measure quality, I'm all for that. I'm not convinced that we have figured out how to do that yet. We have the same problem with scheduler benchmarks, with the difficulty of measuring "responsiveness".

[Veerappan]

Video codec speed benchmarks are futile if not accompanied by comparison of quality at different bit rates.
Please, don't just measure speed.

Not sure about AV1, but back in the days of VP8/WebM any decoder that wanted to claim it could handle that codec had to actually show that it could produce identical output during decoding to what the reference decoder provided. So you could speed it up however you wanted, but it had to produce correct output no matter what.

Encoders, however, could do pretty much whatever they wanted as long as they produced a valid output bitstream.

The multi-threaded decoding, at least, should provide correct output... encoding, well... yeah, who knows.

[_Alex_]

Video codec speed benchmarks are futile if not accompanied by comparison of quality at different bit rates.
Please, don't just measure speed.

I don't think the optimizations done are quality shortcuts. That can always be tuned anyway in every encoding program. The issue is how to properly make the algorithms use the available hardware in the most efficient way.

[quikee]

The multi-threaded decoding, at least, should provide correct output... encoding, well... yeah, who knows.

An encoder must also provide a correct output, but correct in this context means compliant with specs (or the reference decoder if specs aren't written).

[Toggleton]

well av1 encoder are tested(different quality metrics) on https://beta.arewecompressedyet.com/? here a example of libaom vs svt-av1 both speed 0 (VMAF score of all runs) https://cdn.discordapp.com/attachmen...1_14-09-37.png

http://videocodectracker.dev/ "Regression tests for SVT-AV1"