Intel Releases SVT-AV1 1.0 For Speedy AV1 Video Encoding

[arQon]

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.

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.
Years later when you swap out that crappy 19" TN monitor for a 60" OLED, or go to the optician, etc, you realize what you thought was "just as good" is about on par with VGA quality, and it's too late to do anything about it because you don't have the original any more.

Or maybe you don't, because the source was a DVD anyway, or something you recorded on your phone. Maybe you don't notice it until you see the same movie at a friend's place, and it looks "wrong" to you because it's got sharp edges everywhere. Maybe you never notice, because you're a frog in a pot, and the opportunity to compare them never comes up again. But regardless, this is a bad decision, and suggesting it to others is even worse.

> The space saving and ease of decoding even on old machines compensate the awfully long encoding time.

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.

If storage is so desperate that you don't have a choice, then okay, h265 is the right "choice" [1], because it's the only one you have. But the rest of it - the misunderstanding that the quality IS the same, rather than just that YOU can't (currently) tell the difference; and that decode of h265 is somehow more efficient than of h264 just because the stream is smaller - is just plain wrong.

[1] Even then, the electricity you wasted downgrading the quality of your library would have bought you enough TB of disk to just keep the h264 version anyway, AND have a backup of it.

> 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.

You shouldn't be doing either. But in short, the answer is "whatever suits your current needs, and your best guess at your future ones". IOW, if the device(s) you want to watch stuff on can't handle XYZ, then encoding to that in the delusion that you're somehow "future-proofing" your library is just plain dumb in both the long term AND the short term. Similarly, if you expect that a couple of years from now you're going to build an HTPC out of a Pi5, or a retired desktop that's only going to have an IGP in it, or etc, AV1 is the wrong choice.

This isn't theoretical: I've been here before. Back when hard drives were measured in the tens of GBs, and I ripped all my CDs so I could listen to them at will. I chose ogg over mp3 because it was technically superior, and open.
10 years later, when disk space was 1/10 the cost, I had the "joy" of ripping all those CDs again: this time to FLAC, and then *also* encoding them to mp3 for the car and portable devices. The circumstances were beyond my control, and I'd made the "right" choice originally, but it still took literally months of elapsed time to do it, both times. If I'd opted for mp3, or aac, or opus, or *anything* other than FLAC last time, it would have been a mistake that I'd have had to either live with, or waste yet another substantial amount of time recovering from. That's the road you're going down now, except in your case "recovering from it" isn't even going to be an option. I really hope you reconsider while you still can.

Buy more disk space. It's cheaper, AND quicker, AND more compatible (since you're already in h264), AND better for playback. Literally the *only* scenario in which that's not the right move is if you're streaming your video over a metered network.

[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

[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.

[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.

[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?

[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.

[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

[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.

[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.

[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.