Intel Releases SVT-AV1 1.0 For Speedy AV1 Video Encoding

[Chugworth]

I would personally go with a lower preset, as at presets 4-6 is generally the sweet spot for svtav1 outside of realtime which would be 9+ when you pair it with crf which seems to give the best filesize:quality IMO.

another neat trick of svtav1 is time based keyframes which is neato for batch encoding or VFR encoding.



Opus isn't really the "best" it would be tied with the current AAC, also opus has issues with some 5.1 surround sound due to how channels work.

Well for encoding speed, 6 is pretty slow and 4 is unreasonably slow. In comparison of 6 to 8, I just couldn't find much justification in using 6. At 8, the encoding goes even faster than HEVC.

The documentation on FFmpeg's site does mention that it uses a keyframe interval of 2-3 seconds, and consider changing it up to 10. Though I wasn't really seeing much size difference by changing that.

For the audio codec, even if they're about the same AAC is patent-encumbered which gives Opus the advantage. I haven't really tried Opus with 5.1 audio (which is quite rare outside of movies).

[Quackdoc]

ffmpeg -i infile.mp4 -c:v libsvtav1 -qp 35 -preset 8 -c:a libopus -b:a 128k outfile.mkv

At -qp 35, you get better video quality and file size than HEVC with -crf 25. Using -qp 30 would get just slightly better quality, but worse file size than HEVC with -crf 25. I have determined the quality difference to be minor and not worth it. Also, -preset 8 seems to be where it's at. If you go down to -preset 6, then encoding goes much slower and I don't see any meaningful difference either in quality or file size.

I would personally go with a lower preset, as at presets 4-6 is generally the sweet spot for svtav1 outside of realtime which would be 9+ when you pair it with crf which seems to give the best filesize:quality IMO.

another neat trick of svtav1 is time based keyframes which is neato for batch encoding or VFR encoding.

As far as audio, I think it's appropriate to pair it with Opus as that seems to be the pinnacle of audio compression these days. And using a bitrate of 128 is said to be "pretty much transparent" in audio quality for 2-channel audio.

Opus isn't really the "best" it would be tied with the current AAC, also opus has issues with some 5.1 surround sound due to how channels work.

[Chugworth]

Are there any good guides on how to get good results with AV1? Each time I mess with it, I find very little documentation on that and I end up with poor results. Either the video quality is worse than the original or the file size is worse than the original. I'm hoping at some point to find a simple set of switches that will make a nice reduction in file size without making a noticeable difference in video quality.

With HEVC for example, I usually have good results with this simple command:

ffmpeg -i in.mp4 -c:v libx265 -crf 25 -c:a aac -b:a 128k out.mkv

Whoa! It's there now! I have actually been waiting several years for this moment. AV1 surpasses HEVC in quality, file size, and encoding time. I remember doing some testing back around the time I made that post and still not being satisfied with the results. But the ffmpeg distributed through Arch at the time was still using a pre-1.0 libsvtav1. Now they're using version 1.1, I tested it again, and it's there. I'm getting outstanding results. I have tried a bunch of different options, analyzed results, and the sweet spot seems to be this:

ffmpeg -i infile.mp4 -c:v libsvtav1 -qp 35 -preset 8 -c:a libopus -b:a 128k outfile.mkv

At -qp 35, you get better video quality and file size than HEVC with -crf 25. Using -qp 30 would get just slightly better quality, but worse file size than HEVC with -crf 25. I have determined the quality difference to be minor and not worth it. Also, -preset 8 seems to be where it's at. If you go down to -preset 6, then encoding goes much slower and I don't see any meaningful difference either in quality or file size.

As far as audio, I think it's appropriate to pair it with Opus as that seems to be the pinnacle of audio compression these days. And using a bitrate of 128 is said to be "pretty much transparent" in audio quality for 2-channel audio.

[wswartzendruber]

Has anyone gotten noise/grain modeling to work? SVT-AV1 is definitely denoising the picture, but VLC doesn't show anything like the original grain unless the pattern is really intense. My current --film-grain parameter is 8. I would think I should see *something* in the decoded output instead smoothness.

[Anux]

As said, one could easily cheat in a bit rate metric by lowering quality.

But since the purpose of my "benchmark" was comparing the quality, this would easily be spotted.

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

• > Bit rate produced (bits per frame or bits per second)
  will be the same
• > Time to encode
  will be roughly the same
• > Processing power limitations
  same machine
• > Latency (max time to encode a frame)
  there was no real time requirement
• > Perceptual Quality
  thats what we compare

Edit:

I did some tests in the background with ffmpeg 5. Sadly it only provides the -qp mode for av1, therefore I used that and took the resulting bitrate to x264:

.\ffmpeg.exe -y -t 1:00 -i C:\Users\Anux\Downloads\8K60.webm -vf scale=1920:-1 -c:v libsvtav1 -preset 10 -qp 55 -c:a none 1920p60.mkv
frame= 3600 fps= 27 q=47.0 Lsize=    8558kB time=00:00:59.98 bitrate=1168.8kbits/s speed=0.454x

 .\ffmpeg.exe -y -t 1:00 -i C:\Users\Anux\Downloads\8K60.webm -vf scale=1920:-1 -c:v libx264 -preset slow -tune film -b:v 1160k -pass 3 -c:a none .\1920p60.mkv
frame= 3600 fps= 28 q=-1.0 Lsize=    8533kB time=00:00:59.95 bitrate=1166.0kbits/s speed=0.474x

As you can see x264 was allready faster but in the "slower" preset it would have been way slower (0.3x). Still x264 got the better image quality and didn't have the colorshift that you notice with av1.
Also used -pass 3 because pass 2 was significant faster (possibly due to skipping frame analysis).
av1x264.jpg
Apart from those stills the videos look pretty identical with somtimes x264 showing slightly more artifacts and other times av1. Considering that x264 has much better hardware support and is also faster to decode with a CPU there shouldn't be any question what to use (beeing time constrained).

Edit2: get the full resolution here: https://postimg.cc/K1nRcdTY

[arQon]

The files are lectures: just some static slides with a voice-over, and yet they are only around 20 minutes long, they still span several gigabytes due to poor encoding choices (very low bframes, unrealistically high bitrates).

ouch. Yeah, that's not great.

> I do archive the originals on a larger HDD. These transcoded versions are just for accessing them easily on portable devices, mainly laptops.

So yeah: I'd expect the laptops to all have HW support for x264 at this point, and potentially even x265, whereas none of them will support AV1 other than by doubling as space heaters.

> The transcoding is often done with a 20-24 CRF and the highest possible value for bframes. Even when seeing the final result on a larger screen there are no blocking or ghosting artefacts.

20-24 is a little high for typical video content, but may well work well for this sort of thing. (And apparently does).

> I believe I have made a poor choice of words.

Yeah, I figured that wasn't what you really meant.

> The CPUs have no support for accelerated H265 decoding in their iGPUs, yet they still can decode the videos fine, even when played at higher speeds. The CPU usage is higher than when decoding H264, but lower than when doing it with AV1.

Okay: then I think I'd be even more inclined to just go with a "good" x264 encode for now. I don't see the extra bandwidth / disk as being an issue, whereas the difference between pegging every core in the laptop for 30min solid, vs using 2% of one core, seems like a pretty clear win for battery life / power wastage.
Since you're keeping the originals, you can redo them as AV1 a decade from now when that's actually mainstream, and by then you'll be doing it on a machine with twice as many cores and a much more refined encoder too. Seems like an easy call to me.

[arQon]

preset 6 is right now a quite good balance [...] I get about 9fps to 10fps. anecdotally I would say that each of these are better then x264 at the same speed.

Sure, that's versus, what, about 180fps for x264? More? (And that's at "transparency" for x264). Given the unspecified "fixed amount of time" in OP's question, you're talking about 300 minutes - i.e. 5 hours - for a 30-minute presentation. We'll need him to weigh in on what that fixed amount actually is, but it seems very unlikely to me that it's that large.

I'd be surprised if a 60fps AV1 encode really matches the quality of a whatever- (but much higher) fps x264: the x264 will be operating at its peak quality and encoding options, whereas the AV1 will have to abandon the bulk of its potential processing. Certainly possible though, since the majority of that work is just trying to find pans etc. What sort of SSIMs do you get for the stuff you encode with those "fast" presets?

[veikk0]

For SVT-AV1 the command is as follows:

ffmpeg -hide_banner -i inputfile -c:v libsvtav1 -crf 35 -preset 4 -svtav1-params tile-rows=2:tile-columns=1:aq-mode=2:tune=1 -c:a copy outputfile

for the same crf it generally creates a bigger file with less visual quality, either specify lower -crf number for higher quality (even bigger files) or lower -preset (taking much longer to encode) for smaller filesize with same (lower than libaom) quality.

tile-rows=2: every frame is split in 4 rows (speeds up encoding, for a small increase in filesize)
tilecolumns=1: every frame is split in 2 columns (speeds up encoding, for a small increase in filesize)
aq-mode=2: best quality for normal video (range (0-2)
tune=1: use psnr tuning (or 0 use VQ better quality but very much larger filesizes)

Unlike libaom, SVT-AV1 doesn't use tiles for encoding parallelism, so you're basically throwing away quality for no performance gain here.

If you're using tiles for higher decoding performance, you should try --fast-decode=1 first.

[guara]

artifacts

Then TBH you aren't really looking. Which is fine today, since the point is that your goal is specifically "Can I tell the difference?" on your current TV / monitor / whatever, with your current eyesight, and your current speakers, for the content that you're using. But generational loss is well understood, and you *imagining* that it doesn't exist isn't the same as it not existing, even in a case as perceptual as this.

The files are lectures: just some static slides with a voice-over, and yet they are only around 20 minutes long, they still span several gigabytes due to poor encoding choices (very low bframes, unrealistically high bitrates).
I do archive the originals on a larger HDD. These transcoded versions are just for accessing them easily on portable devices, mainly laptops.
The transcoding is often done with a 20-24 CRF and the highest possible value for bframes. Even when seeing the final result on a larger screen there are no blocking or ghosting artefacts.

Wut? I would love to see this mythical old machine of yours where h265 has "ease of decoding" over h264: it would transform our current understanding of basic math and/or electronic principles. :P Less disk space, sure. But that, no.

I believe I have made a poor choice of words. The CPUs have no support for accelerated H265 decoding in their iGPUs, yet they still can decode the videos fine, even when played at higher speeds. The CPU usage is higher than when decoding H264, but lower than when doing it with AV1.

[Quackdoc]

Both of the previous replies to this are "correct", but Anux's is closer to answering the question you're "really" asking: x264, by at least a noticeable amount, probably a large amount, and quite possibly a staggering amount.

That doesn't make Quackdoc's reply any less valid though, other than that unless your "fixed amount of time" is quite large AV1 won't even get off the ground. (At least, not historically, and this release isn't going to change that). His main point though, that this is *always* about juggling tradeoffs of one kind or another, is worth repeating.

This isn't true anymore IMO, i've been using SVT-AV1 for real time encoding a decent amount now preset 9 or 10 depending on if I need 30fps or 60+ fps as preset 9 can't quite handle 60fps on my 2600 (gets about 56 fps 1080p content) while preset 10 gets about 80-100 fps, pretty good quality. for slower then RT preset 6 is right now a quite good balance, without using a tool like av1an, I get about 9fps to 10fps. anecdotally I would say that each of these are better then x264 at the same speed.

that being said, if I need faster then realtime, I would still likely opt for x264.

Are there any good guides on how to get good results with AV1? Each time I mess with it, I find very little documentation on that and I end up with poor results. Either the video quality is worse than the original or the file size is worse than the original. I'm hoping at some point to find a simple set of switches that will make a nice reduction in file size without making a noticeable difference in video quality.

With HEVC for example, I usually have good results with this simple command:

ffmpeg -i in.mp4 -c:v libx265 -crf 25 -c:a aac -b:a 128k out.mkv

Check the AV1 subreddit and search for Bluesword, he has some quite good guides on usage.

Yeah, I got a Razer Phone 2 with an SD845 as well. Last I checked with mpv-android, it works, but drops a few frames and really heats up (whereas hardware h.265 decoding is flawless).

yeah you won't find great use if you have a HW accelerated device unless you need the bandwidth savings of AV1.

EDIT: aside from preset 10 I find they can be comparable preset 10 is kinda bad