Intel Releases SVT-AV1 1.0 For Speedy AV1 Video Encoding

[phoronix]

Phoronix: Intel Releases SVT-AV1 1.0 For Speedy AV1 Video Encoding

Intel in cooperation with the Alliance for Open Media has done on a terrific job on the development of SVT-AV1 for open-source, high performance CPU-based AV1 video encoding. This morning marks the release of SVT-AV1 1.0...

https://www.phoronix.com/scan.php?pa...1-1.0-Released

[uid313]

Could they use oneAPI for this?
This is CPU-based AV1 video encoding, but what if they wanted to video encode using their Intel Xe integrated graphics or Intel Arc Alchemist graphics card?
Then they just call a function that takes byte array stream and passes it into a dedicate AV1 encoder on the GPU silicon?

[Quackdoc]

Could they use oneAPI for this?
This is CPU-based AV1 video encoding, but what if they wanted to video encode using their Intel Xe integrated graphics or Intel Arc Alchemist graphics card?
Then they just call a function that takes byte array stream and passes it into a dedicate AV1 encoder on the GPU silicon?

I think you are talking about OneVPL.

[RealNC]

The "benchmark" I would love to see but is difficult to perform, is a comparison between SVT-AV1 for encoding to AV1 and x264 for encoding to H.264 and comparing the quality between the two when encoder settings are used that result in the same encoding time.

That is, if I have a fixed amount of time to spend on encoding a video, would that time be better spent using SVT-AV1 or x264? Right now, everything I can find is that AV1 is higher quality or same quality but with smaller file size, but needs more encoding time. Which is rather useless when I care about time much more than I care about size. (Within reason, of course.)

[Quackdoc]

The "benchmark" I would love to see but is difficult to perform, is a comparison between SVT-AV1 for encoding to AV1 and x264 for encoding to H.264 and comparing the quality between the two when encoder settings are used that result in the same encoding time.

That is, if I have a fixed amount of time to spend on encoding a video, would that time be better spent using SVT-AV1 or x264? Right now, everything I can find is that AV1 is higher quality or same quality but with smaller file size, but needs more encoding time. Which is rather useless when I care about time much more than I care about size. (Within reason, of course.)

it depends. it's not a B&W question. how much compression is needed, what IS the time constraint. how much CPU horse power do you have. everything is a balancing act.

[Anux]

If you only care about encoding time and not file size x264 --preset ultrafast with --crf 0 wins, no need for a benchmark.

Its certainly would be interesting if you include "same file size", a test that you could easily do yourself. Get a video, compress it with SVTs fastest preset , put "time" in front of the command line and make shure you give a low bitrate value so that your videos don't approach transparency.
Then repeat the same with x264 at medium preset and change its presets till you roughly match the SVT time.
The shorter your source video, the faster you get your answers. More and longer videos give you better accuracy and using 2 passes gets you closer to your target bitrate.

Its pressing a few buttons and waiting and pressing buttons and waiting ... or write a script once and do it over night. Been doing stuff like that back in the days when DVDs still were a thing, mostly to get the best quality at 700 MB .

[dreich]

That is, if I have a fixed amount of time to spend on encoding a video, would that time be better spent using SVT-AV1 or x264?

If you have a fixed amount of network bandwidth for each client to watch 4k video you might reconsider. AV1 will be about half the file size for 4k video compared to what x264 can do. This is significant for streaming companies like Netflix and Google.

Right now, everything I can find is that AV1 is higher quality or same quality but with smaller file size, but needs more encoding time.

This is the guiding principle for most codecs. You increase complexity and improve coding efficiency. It would not be nearly as valuable to develop a codec that produces worse quality for the same file size.

[brucethemoose]

The "benchmark" I would love to see but is difficult to perform, is a comparison between SVT-AV1 for encoding to AV1 and x264 for encoding to H.264 and comparing the quality between the two when encoder settings are used that result in the same encoding time.

That is, if I have a fixed amount of time to spend on encoding a video, would that time be better spent using SVT-AV1 or x264? Right now, everything I can find is that AV1 is higher quality or same quality but with smaller file size, but needs more encoding time. Which is rather useless when I care about time much more than I care about size. (Within reason, of course.)

I haven't tested that specifically, but I'm pretty sure it's a straight upgrade over straight 10 bit x264 veryslow, and that there's not a preset faster than x264 fast (which is comically fast these days).

Encoding certain kinds of content is particularly annoying with straight x264 8 bit though, as dark scenes or flat gradients will look crushed/banded even with tons of bitrate.

Anyway, av1an basically does what you're asking with its "target-quality" flag. If you are interested in speed, you should already be using it as a frontend anyway, as it can effectively thread x264 and other encoders, while also producing better videos than x264 can alone (by varying the parameters from scene to scene).

[guara]

The "benchmark" I would love to see but is difficult to perform, is a comparison between SVT-AV1 for encoding to AV1 and x264 for encoding to H.264 and comparing the quality between the two when encoder settings are used that result in the same encoding time.

That is, if I have a fixed amount of time to spend on encoding a video, would that time be better spent using SVT-AV1 or x264? Right now, everything I can find is that AV1 is higher quality or same quality but with smaller file size, but needs more encoding time. Which is rather useless when I care about time much more than I care about size. (Within reason, of course.)

It would be nice to add H265 too.

I recently started transcoding all my old H264+AAC files into H265+Opus (CRF mode). Even though they are only 1080p videos, the savings are excellent and I could not detect any degradation in the video or audio quality. The space saving and ease of decoding even on old machines compensate the awfully long encoding time.

Yet, I would like to know: should I be doing AV1+Opus instead of H265+Opus? AV1 encoding and decoding hit way harder on my ageing CPUs than H265.

[juarezr]

If you only care about encoding time and not file size x264 --preset ultrafast with --crf 0 wins, no need for a benchmark.

Its certainly would be interesting if you include "same file size", a test that you could easily do yourself. Get a video, compress it with SVTs fastest preset , put "time" in front of the command line and make shure you give a low bitrate value so that your videos don't approach transparency.
Then repeat the same with x264 at medium preset and change its presets till you roughly match the SVT time.
The shorter your source video, the faster you get your answers. More and longer videos give you better accuracy and using 2 passes gets you closer to your target bitrate.

Its pressing a few buttons and waiting and pressing buttons and waiting ... or write a script once and do it over night. Been doing stuff like that back in the days when DVDs still were a thing, mostly to get the best quality at 700 MB .

Benchmarking video codecs is a very complex thing. A "same file size" is often not enough to evaluate a codec performance.

As said, one could easily cheat in a bit rate metric by lowering quality. A less efficient and poorly tuned codec would generate the same bit rate with washed frames as a codec with more advanced algorithms and tuning that could generate sharper and more accurate images.

Commonly video evaluation implies on balancing the metrics for the use case. E.g:

• Bit rate produced (bits per frame or bits per second)
• Time to encode
• Processing power limitations
• Latency (max time to encode a frame)
• Perceptual Quality
  • SSIM, PSNR, CIEDE, VMAF, etc...
  • Human subjective evaluation (synthetic metrics are far from perfect / conclusive)
  • Human preferences (sharper, brighter, color, contrast, etc...)
  • artifacts on the picture, noise, etc...