Thread 106327782

M6 SVT-AV1 is now FASTER than slow preset x264!

So after some tinkering I finally decided on a good H264 vs AV1 comparison. The most common and very overkill x264 encode setting seems to be the slow preset + CRF 20 so I'll do my best to match this with AV1. The whole reason we even do video encoding in the first place is to get rid of encodes that take up too much space and even though I have a lot of blu-ray x265 rips I found something better that you can download without worrying about piracy!

https://mango.blender.org/download/
http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/ToS-4k-1920.mov

704 MB Reference video file: H264, 1920x800, 24 FPS, 7862 Kbps, ~12 minutes duration

CPU used for test: i5-8400 [6 CPU cores @ 2.8 - 4.0 GHz], released in 2017

... -c:v libx264 -crf 20 -preset slow
frame=17620 fps= 28 q=-1.0 Lsize= 417973KiB time=00:12:14.08 bitrate=4664.4kbits/s speed=1.15x
Quality validation passed (excessively), VMAF mean = 98
Encoding speed = 28 frames per second
408 MB, 4664 Kbps = ~41% lower bitrate vs bloated reference x264 rip

... -c:v libsvtav1 -preset 6 -crf 28
frame=17620 fps= 32 q=28.0 Lsize= 222269KiB time=00:12:14.12 bitrate=2480.3kbits/s speed=1.34x
Quality validation passed (excessively), VMAF mean = 97
Encoding speed = 32 frames per second
217 MB, 2480 Kbps = ~69% lower bitrate vs bloated reference x264 rip and ~47% lower bitrate vs CRF 20 slow x264 rip

>>106327782 (OP)
Doesn't matter. You'll end up watching somebody else's uoload of the same slop on youtube.

>>106327782 (OP)
Built for VVC

OK but what about the quality and filesize.

>>106327871
It's kinda disappointing how little of an advantage VVC has over AV1. I expected better and even if you encode it at 0.1 FPS, the 100 FPS AV1 encode isn't going to be that much bigger in file size lol.

>>106327997
That's what the other half of my OP tested. Sorry I couldn't condense this into a fucking 10 second shit tok for your short attention span anon.

Here are the FFMetrics for the slow CRF 20 x264 rip with SSIM and VMAF visualized if anyone is curious.

And here are the FFMetrics for the M6 CRF 28 SVT-AV1 rip with SSIM and VMAF visualized if anyone is curious.

>Finally supported on Discord
>But still not this place
Sigh.

https://files.catbox.moe/2ozj7e.webm
https://files.catbox.moe/dpgpth.webm
https://files.catbox.moe/ctx5xb.webm
https://files.catbox.moe/7yg00c.webm
https://files.catbox.moe/iolsff.webm
https://files.catbox.moe/1wc0kq.webm
https://files.catbox.moe/04n3aw.webm
https://files.catbox.moe/df8bgp.webm
https://files.catbox.moe/mknmic.webm
https://files.catbox.moe/sosczh.webm

The overkill x264 and AV1 rips are too big for catbox so the best I can do is post a CRF 30 M6 SVT-AV1 encode, which unsurprisingly still passed quality validation at 96.66 VMAF.

https://files.catbox.moe/74jz6l.webm

A little bit more on the quality validation aspect of this test. In short you only need to exceed 95 VMAF as this is the rough score that causes people to fail to distinguish the original video and the lossy copy. Some genetically gifted people might require higher scores and some lower scores but it's generally agreed that a once you exceed 95 less than 10% of the human population will be able to make any kind of distinction of which is which. As you exceed 95 VMAF the file size bloat will get worse and worse so keep that in mind.

>>106328249
It truly is such a sadness. VP9 is a slow complex mess and few anons here seem to make encodes better than slow x264 rips desu. Like it's "b-frames" won't even fucking work unless you explicitly enable them through a 2 pass encode and even then you're gimped if it's 8-bit, so only 10-bit 2-pass VP9 encodes are worth the squeeze but then you have to worry about anons who don't have the 10-bit VP9 decoder.

>>106328249
These catshit box links never work

>>106327782 (OP)

> M6 SVT-AV1 is now FASTER than slow preset x264!

You are not helping the cause by posting much older BD-rate graphs where M6 SVT-AV1 was still MUCH SLOWER (almost by an order of magnitude!) than slow preset x264, you know.

Which GUI encoder should I dowbload in order to test this update?

>>106328895
I can't find the updated graph but I hoped people would put 2 and 2 together given the FPS I got...

>>106328991
I used to use staxrip for my HEVC encodes, that might work for you.

>>106328895
Contrasting contemporary results with those initially published gets the point across to anyone who wasn't dropped as a baby.

>>106328991
On Linux, everything just leeches off the system's SVT library, so you can be certain that you're up to date.

>>106328460
Catbox can be slow, but it never didn't work on my PC.
https://youtu.be/dw8BZgHcb2A

>>106329525
>never didn't
You didn't do nothing man!

What about decoding, has that improved?? Tesla reversed their decision to support AV1 because it was causing video playback problems.

https://streaminglearningcenter.com/codecs/tesla-rolls-back-youtube-from-av1-to-vp9.html

If your sourcefootage is noisy AV1 is technologically incapable of preserving detail.

>>106331343
If you DID intend on making sure your noise video was faithfully reproduced then you'd need 100 Mbps. A much saner option is AFGS1 which has been out for like a year.

https://norkin.org/research/afgs1/

>>106331285
No clue but I get about 400 FPS decoding my OP AV1 1920x800 rip on a 2017 i5-8400 through DAV1D 1.4.2 and the latest version is 1.51 but the former is what openbenchmark has. Only really old laptop CPUs should have any problem decoding AV1.

https://code.videolan.org/videolan/dav1d/-/releases

>The Intel Atom processors in older Teslas simply couldn’t keep up, leading to stuttering and buffering.
OK now it makes sense. Kind of batshit insane that Tesla would be using these things in $50-80k cars though...

>>106331285
>tesla does something
nobody gives a fuck

daiz.... please stop

>>106332956
?

>>106327782 (OP)
for me? it's ultrafast+fastdecode

>-c:v libx264 -crf 20 -preset slow
>-c:v libsvtav1 -preset 6 -crf 28
isnt -crf 28 gonna be worse than -crf 20?

>>106334592
To make it more of a fair comparison of encoding time, he should have done a bitrate encode.

>>106334592 (me)
i tried tests with -crf 28 and -b:v 500k and av1 always had worse file size. and worse speed.

>>106334592
CRF numbers aren't compatible across codecs unfortunately. Both encodes passed quality validation.

>>106334624
Sorry, I'm only interested in video that passes quality validation. Then again both of these encodes were wayyy above VMAF 95 so I might re-do the test to like 95.5 or 96.

>>106335068
Was this libaom or libsvt? I don't understand why you'd use a biteate limit with CRF, that kind of defeats the purpose of CRF.

>>106336517
no i tested both crf and bitrate separately and it was with libsvt
both had equal bitrate and equal crf set
>CRF numbers aren't compatible across codecs unfortunately.
sorce?

>>106336587
My CRF 28 M6 libsvt AV1 OP encode literally passed quality validation. You can use FFMetrics if using vmaf directly is too difficult for you as shown in >>106328218 and >>106328234

>>106328234
>>106328218
vmaf on the x264 seems higher, isnt that better

>>106336886
By like 1% with no perceptible quality improvement. Aligning the VMAF scores might require 2 pass encodes so I'm not in a rush to make that thread desu.

Both 97 and 98 are pretty overkill. You only need to exceed 95 so 95.5 or 96 are more reasonable targets to avoid wasting space.

>>106327782 (OP)
even doe H265 is better than SVTAV1

>>106337838
What encoder? x265 gets suplexed by M6 libsvtav1. Even placebo x265 fails to match M6 libsvtav1.

>>106337922
that picture is of libamen encoder, not fair to compare libamen to x264

I stopped caring when my hard drives got bigger

>>106337953
AFAIK there's like a 5% difference between the AOM and SVT encoder. Anyway you didn't answer my question, which HEVC encoder are you talking about? Because there's many just like there are AV1 encoders.

Spoiler alert: even if a snowflake HEVC encoders outperforms M6 libsvtav1, it's probably going to be like 10X slower lol.

>>106337981
i am talking about libx265 on debian 12, it outperforms libstav1 on speed and quality is 1 vmaf lower

>>106337968
Interesting. May we know what FFFUCKING TELEPHONE you might be using with a 16TB hard drive slot?

>>106337953
AOM is only marginally better than SVT at its slowest preset. Once you compromise on effort, SVT runs circles around it.

>>106337995
What's the video source? Unfortunately AFGS1 was only released a year ago so that might explain this anomaly.

>>106327782 (OP)
i hate namefags but you brought libstav1 to my attention and i really need a good quick-ish encoder
so thank you
i can encode h265 on my gpu (HEVC_NVENC), is libstav1 worth it? any comparisons? i can use the slowest preset and still get 5-10x over a normal video speed

>>106338003
whatever one direct plays flawlessly from my jellyfin base

>>106338039
>slowest preset
with HEVC_NVENC
whereas av1 with your (op's) command its a bit slower

>>106338039
Very. Only the AV1 GPU encoders compete with libsvtav1 in speed and even then M8 will encode 1080p at like 100+ FPS on a modern CPU so it's not like GPU video encoding is 10X faster anymore.

SORRY, it's 200+ FPS for M8 1080p libsvt on a modern CPU and that's assuming you set a fucking laptop 8-core Zen 4 ryzen using 25W of power as the minimum lol.

>>106338069
uhh anon i was talking about nvidia nvenc h265, its not in the pic
HEVC_NVENC competes in speed very much so compared to libstav1
probably because i only have an intel i5 12400f
but im asking about quality, a few years ago i tried looking for comparisons between H265 and AV1 and I wasnt able to find any proper ones

>>106327782 (OP)
>libx264
muxing overhead: 0.126888% frame=17620 fps= 75 q=-1.0 Lsize= 431457KiB time=00:12:14.08 bitrate=4814.8kbits/s speed= 3.10x
>libxvt
muxing overhead: 0.177419% frame=17620 fps= 86 q=28.0 Lsize= 225555KiB time=00:12:14.12 bitrate=2516.9kbits/s speed=3.57x
>h264_videotoolbox
muxing overhead: 0.045029% frame=17620 fps=259 q=-0.0 Lsize= 937541KiB time=00:12:14.12 bitrate=10461.9kbits/s speed=10.8x

>>106338179
wtf is libxvt

>>106338160
>i5 12400f
Yeah, you fucked up REAL bad m8. intel had AVX-512 on 11th gen but they decided to make it a pro™ feature for 12th gen.

Also NVENC especially with the slow presets does seem to compete with x265 slow preset from what I've heard but even that won't get you preset 8 SVT-AV1 quality.

>>106338231
a-atleast 12th gen was a performance boost..

>>106338179
LMFAO @ videotoolbox jacking up the bitrate to 10 Mbps when the source was 8 Mbps. So THIS is the power of hardware encoders...

>>106338256
>h264_videotoolbox -c:v 4800K
muxing overhead: 0.095775%
frame=17620 fps=259 q=-0.0 Lsize= 441010KiB time=00:12:14.12 bitrate=4921.2kbits/s speed=10.8x

>>106338296
>-c:v 4800K

>>106338348
i'm tired

>>106338365
can you tell me what libxvt is tho

>>106338377
libsvtav1, also a typo

im a rtx 3060 12gb + i5 12400f 64gb ddr4 god
what codec should i use?

>>106339065
If you have that much RAM then you probably don't need anything more than nvenc hevc desu. Cramming 1080p movies down to 1 GB with good quality is only a concern for people with phones/computers with a 256GB SSD or worse.

>>106339129
i only have 3tb of hard drive space and im slowly running out. and my ssd is full of LLMs
i cant exactly fill my motherboard with many hard drives because im extremely paranoid about data loss so im running two 3tb ones at raid 1
but i also sperg about wasting any space

is dav1d the fastest av1 encoder?

>>106339629
No, that would be NVENC AV1 but you must pay the RTX 5000 tax to get it. Dav1d is the software decoder trying to help poorfags with 10 year old devices not miss out on the benefits of AV1.

I've heard rumors that it's going to be better than QSV AV1 so it might achieve M8 libsvt compression efficiency but even then I'd still argue for libsvt since you're probably going to pair this with a modern super fast CPU... I hope.

Like what kind of a nut would buy an RTX 5060 for his 2500K rig lol?

>>106339687
i5 12400f is modern fast cpu :3?

>>106339701
ye, I only get 32 FPS on my i5-8400 old timer but I still won't touch QSV AV1 even if I got an arc dGPU.

what should i do if i have an already lossy video from 4chan?

>>106339776
Just leave it as-is. AV1 is cool and all but it's not going to help you compress webms with mp3 bitrates for video any further without degrading quality disastrously. I don't think 4chan has even realized how much damage they did when they allowed H264 MP4 uploads. It increased compatibility/accessibility at the cost of utterly destroying quality here.

>>106339864
Actually, it allows people to leave said video as is without having to go through the non-idiot-proof procedure of encoding a video. Now, the issue is that popular video-sharing platforms like Discord have a slightly higher size limit, so many of them will need to be recompressed either way, which is where AV1 .mp4 comes in. It would be nice to see parity through a raised 8MB limit, but a part of me wants the status quo to remain in order to rationalize my 6MB efforts.

>>106340365
Realistically H264 is such a shit ass codec in practice that a 20MB file size limit would realistically be better suited to avoid lossy to lossy compression especially since the retard websites doing server user upload x264 encodes don't even use CRF mode but a stupid arbitrary CVBR that may or may not be enough. 4chan already struggles to quickly load 6MB filesize webms so increasing it even to just 8MB would fuck it up for everyone here even more IMHO.

>>106328408
>The overkill x264 and AV1 rips are too big for catbox
https://litterbox.catbox.moe/

Neither scene, most p2p or animu groups use av1, so i don't care.

How does it compare with x265? Should I be reencoding archived x265 footage to save space?
I wish Premiere supported it...

>>106327782 (OP)
>1920x800

>>106332956
he is actually still around randomly
the magic is gone tho

>>106342064
Unfortunately this would get epsteined in 3 days. However I did include the parameters used so reproducing them shouldn't be a problem.

>>106342545
Understandable cautionary aversion. Back in 2020 it was assumed that AV1 wouldn't be adopted until 2030 because GPU decoding was thought to be a hard requirement for decoding it.

However Dav1d, a CPU AV1 video decoder has added a mind boggling amount of backward compatibility going all the way back to a 2011 2500K if not further than that. Really really low end CPUs will still struggle like atom CPUs found in $80,000 teslas for some retarded reason but the majority of CPUs from more than a decade ago now have no problem decoding AV1 video. Also CPU encoding AV1 video through libsvtav1 is now faster and achieves significantly smaller file size at high quality than CPU encoding H264 video through x264 as proven by this thread SO THERE'S THAT TOO...

I honestly don't see why encoding groups haven't adopted AV1 yet. Maybe they're not as smart as they claim to be when it comes to video encoding stuff.

>>106342578
M6 libsvtav1 OUTPERFORMS x265 placebo in terms of quality and speed. Another slower HEVC encoder might be able to maybe match M6 libsvtav1 but it's definitely going to be slow as balls.

>>106342579
It's cinematic(tm) anon.

>>106327782 (OP)
Worthless lying nigger av1 is slow as shit and the speed gains are tiny, svtav1 last release was on avg 4% speed-up and it took them five months
kill yourself retarded shill

>>106343728
OP isn't lying but he's not comparing x264 using the fast preset, he's comparing x264 using the slow preset.

So yeah sorry m8 svtav1 is still going to be slow on your dual-core Pentium CPU. I don't know what to tell you man. Just keep encoding video with x264 using the fast preset I guess...

>>106343832
>but he's not comparing x264 using the fast preset, he's comparing x264 using the slow preset
as if it had any fucking importance
yea okay get fucked
latest ffmpeg version which uses the newest svtav1

>>106343917
>yuv420p10le
OP never mentioned 10-bit being used you dumb ape.

>>106343832
>svt-av1-2.16
>when v3 came out almost a year ago
av1 fags on /g/ are one of the stranger weirdos
>>106342808
>Maybe they're not as smart as they claim to be when it comes to video encoding stuff.
Or maybe it’s (you) who is a know nothing retard and not everybody else

>>106344064
the sheer fucking state
If you use av1 and encode to 8bit you’re not only disingenuous but actively retarded

>>106344108
10-bit doesn't help at high quality, ONLY at low quality or if the source itself is 10-bit. I don't see any information suggesting OP's video source is 10-bit.

Duration: 00:12:14.17, start: 0.000000, bitrate: 8051 kb/s
Stream #0:0[0x1](eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1920x800 [SAR 1:1 DAR 12:5], 7862 kb/s, 24 fps, 24 tbr, 24 tbn (default)

>>106344142
You don’t deserve a full reply to have some ai slop telling you that you’re dumb

>>106343917
>>106344064
>>106344108
>>106344142
>>106344250
That's interesting, according to vmaf there's pretty much no quality improvement going from 8-bit to 10-bit. I guess the quality really is so high that 10-bit doesn't offer any meaningful advantage here. Both achieved similar bitrates too btw.

10-bit av1 vmaf: 97.2310

8-bit av1 vmaf: 97.0109

So encodes like this are in fact "bloat"? They seem pretty small though.

>>106344419
vmaf is just a tool that won’t even care about very visible gradient on the sky etc. it’s not the end-all of visual quality

>>106344466
It seems to align really well with human opinion. Is there a better video metric that I can use?

https://www.researchgate.net/figure/Evolution-of-the-VMAF-scores-and-the-normalized-DMOS-with-the-QP-value-for-each-content_fig5_330511661

>>106327782 (OP)
That's nice. I'm not implementing AV1 in my encoder script until 4chins supports it. As for archiving video, x265 works well enough for now.

>>106344509
>Is there a better video metric that I can use?
Your eyes. Tools like that are an approximation at best, which is why every guide under the sun tells you to make some test encodings and check for yourself if it’s something whose quality you truly care about

>>106344572
lol I'm not going to watch thousands of hours of video.

>svtav1 is currently developed, with major changes being released every few months
>ni/g/gas using charts from over a year ago
huh?

>>106344949
Videocoding fags are retarded autists. They always obsess over some irrelevant metric and will spend hours doing comparisons. Complete waste of time. If they knew what they were doing they'd be upstream contributors but they ain't, and they never will be.

>muh freetard gay-v-1 autism
who cares
h.264 for posting on the internet
h.265 for personal use, tiktok, anime, and bluray
simple AS

>>106344419
nice anime

>>106327782 (OP)
>https://www.gyan.dev/ffmpeg/builds/
Does the latest gyan.dev ffmpeg build have this?

>>106344617
you already have

>>106345304
Sisvel lost.

>>106327782 (OP)
are you knowledgable about this stuff?
how does the av1 uhq nvenc encoder on the rtx blackwell cards compare?
It encodes so much faster than cpu and it doens't look bad visually. I have a ffmetrics of some encodes I did with it.

I thought for ffmetrics to be valid you had to make the videos the same resolution?

>>106345304
BOTH are becoming obsolete to AV1 desu. But H264 is especially becoming redundant now that it's SLOWER to encode compared to AV1.

It's pretty accurate to say that H264 is becoming the next DIVX desu. It's not 100% that status yet but it's getting there.

>>106346491
Yup, that's what I'm using.

>>106349173
No clue but the rumors are that it might achieve parity with M8 libsvtav1. Even uf that does happen you still have M8, M7, M6, and everything else if your CPU isn't a potato.

>>106349173
>I thought for ffmetrics to be valid you had to make the videos the same resolution?
Yeah and that's what I did. I double checked and both the original and lossy encodes were 800p. See >>106328218 and >>106328234

>>106349173
>hardware encoding
it's SHIT
never use hardware encoders if you have the choice

>>106327782 (OP)
>... -c:v libsvtav1 -preset 6 -crf 28
huh? whats the full setting? cause when I try it with a sample video, it just doubles the file size from 20MB to 38MB

Links related
>https://files.catbox.moe/cvkcoo.mp4

>ffmpeg -i input.mkv -c:v libsvtav1 -preset 6 -crf 28 output.mkv

The input is ~5Mbps and the output is 10Mbps file, that is not right.

>>106350193
Your MP4 has a VP9 video stream, wtf. Anyway you misunderstand, this is just a codec test against H264 with using a bloated H264 video file as the reference. Not all 1080p videos are equal, some just have too much random motion complexity and the reference H264 might require 20 Mbps or more. That's why 1080p blu rays are 25 Mbps or higher to account for that.

Anyway that looks like a pretty fucking good VP9 encode if AV1 can't reduce the file size further without obliterating quality. That or it's bitstarved given the motion complexity...

>>106350999
Its just standard youtube video download via yt-dlp. Youtube's internal vp9 encoding.

>>106351394
Alright so that narrows it down to severe bitrate starvation then lol. Strange how a dancing anime girl requires ~20 Mbps on the H264 master. Maybe it's the lights or something too idk.

>>106351472
Whatever the case is, encoding should NEVER produce larger file size. Its just fake data being put in at this point

>>106351521
Some 1080p videos are just cursed. They will fail to pass quality validation at anything below 20 Mbps even with modern video codecs. They look like videos to us humans but to video encoders all they see is random noise and they have a hard time compressing that.

So while AV1 will ON AVERAGE outperform H264 by 50% there will be freak edge cases like picrel.

>>106351521
AT LEAST we have AFGS1 to deal with old grainy footage, that shit haunted x265 for the longest time. Like 0 compression efficiency improvement vs x264 on DVD video released before 2010.

>>106351753

you fuckers do not believe spec says 30 Mbps for 720p i have no idea what fullhd should be

>>106350031
i'm getting 380 fps and the quality will be good. I'll run some ffmetrics to test for the sake of this thread.

>>106352745
Just keep in mind that quality validation only happens above 95 VMAF. So 95.5 is enough.

>>106352864
How do I check the quality encoding a 4k video down to 1080p?

>>106352913
Just make a bloat encode first but since it's not clear if av1 nvenc will even pass quality validation a -crf 0 libsvt encode would be great if you have the space for it.

>>106352944
bloat 1080p encode to use as the reference video, that is.

>>106352952
what settings do I need for that? The original 4k video is 21k bitrate

>>106352961
dunno, depends if av1 nvenc passes quality validation or not. If in doubt you're gonna have to go with crf 0 which nvenc might not be able to do so you're probably gonna have to use libsvtav1 for that

>>106327782 (OP)
(((av1)))
please re-encode the needful saar

>>106352961
You shouldn't need any special settings, just use the scale vf to drop down to 1080p res and yuv420p should be transfered automatically.

>>106352988
nah that would be vvc. AV1 doesn't have royalty fees like vvc.

>>106352986
CQ 0 give me a 256 MB/s video. kek

>>106352986
what preset should I use for the cq 0 video?
preset 8 is giving me 29 fps....

>>106353132
Preset 10 is fine. This should be lossless afterall but like 20% bigger or something like that.

You don't need to do an hour of video man, 5 minutes is more than enough desu. Just need to capture some moving and still scenes of a video.

>>106353159
The video I have doesn't really have any motion until 40min into it. Yeah I know I can spit out preview clips with handbrake but I already have 7 full encodes with the gpu since it goes so fast.
The CQ 29 settings nvenc encode looks pretty good and it's only 4.4k bitrate.
63 avg fps on this current encode.

ffmetrics seems to take forever to crawl through the video. It doesn't seem like there's a speed difference from telling it to skip segments of the video vs not skipping at all.

vmaf scores from 10 minture duration, skip 5 min.
Even 2.5 Mb/s cbr gets 95.36 vmaf.

>>106353828
Yeah this is the part that blows. nvidia made a cuda port but ffmetrics doesn't have this as an option unfortunately. The ffmpeg one works but you can't

https://developer.nvidia.com/blog/calculating-video-quality-using-nvidia-gpus-and-vmaf-cuda/

>>106354006
Wyat does the plot look like? Any significant long term dips in quality (ie below 90 vmaf)?

But dam this looks like M8 libsvtav1. Only thing left is to confirm it by comparing it to -c:v libsvt -crf 30 -preset 8

>>106354061
i'm encoding a cq 30 preset 2 encode with svt-av1 but it's going to take 2 hrs 27 min

>>106354061
This is what I got. I though the constant quality settings would be the same between the encoders yet nvenc highest quality at cq 29 scores the same as svt-av1 cq 30 preset 2?