What is intel "quicksync"?
Isn't it just hardware acceleration on the iGPU?

>>106195651 (OP)
Ye, it's another fucking GPU video encoder. It's all dogshit except AV1 quicksync and even then you should only use it as a last resort to libsvt.

>>106195690
sasuga Intel
always crapulent, kek

>>106195651 (OP)
boring anime, and Derptania is the worst part about it, to be quite Frank, Betty, and Bob with you

>>106195651 (OP)
Its a separate hardware encoder, its not GPU specifically
Welcomes to nearly 20 years ago

>>106195690
>It's all dogshit except AV1 quicksync and even then you should only use it as a last resort to libsvt.
what's even the point then?

>>106195690
>it's all dogshit
nta but isn't intel's/nvidia's encoder for h264 almost on par with x264 veryslow? they only seem to be significantly behind the software counterpart for h265 and even then seems like a good compromise

>>106196361
>its not gpu specifically
yes it is retard, F series cpu that lack a gpu don't have quick sync, it's still contained inside of the gpu silicon, it just uses dedicated asic hardware instead of regular compute/shader cores but that's about it

>>106198295
Yes as far as I know it's quite good post alchemist for almost every major codec even compared to nvidia. No idea what >>106195690 is talking about, of course software encoding/decoding will always be better fidelity but hardware encoding/decoding is about speed and low power.

>>106198295
>>106198515
You are not going to pass quality validation at low bitrates with GPU encoded video. That's just how it is.

However intel's quicksync AV1 can reach "good enough" for a lot of people. But why settle for 2nd place when libsvt CPU encoded AV1 is becoming so fast that you can encoded it on a telephone?

I mean it literally btw and from an efficiency perspective encoding AV1 video via CPU on a modern day Android smartphone is pretty competitive with a desktop computer consuming like 50-100W idle.

>>106198831
I literally said hevc is the exception to this and you just posted an hevc comparison
...actually, it's hevc vs av1?
yes I understand that more recent codecs are faster to software encode compared to older ones but that's still an unfair comparison
no matter how good that software av1 encoder is, it will never be as low overhead/power as an HW encoder and besides, you usually pick codecs based on compatibility.
and why not compare nvenc av1 with this av1 software encoded at that point?
>>106198846
>svt-av1 preset 5
that's like on par with latest gen hevc nvenc yeah

>>106198936
>>svt-av1 preset 5
>that's like on par with latest gen hevc nvenc yeah
LOLWUT????

You're thinking of preset 10 and that's being VERY conservative.

>>106198936
Also let's say a modern Android phone can only do 60 FPS at 1080p using libsvt. A desktop computer will idle at 50-100W while the Android phone will use a few watts of power UNDER LOAD.

>>106198305
The physical location on die doesn't matter, you gay idiot. You yourself just acknowledge that is isn't IGP, its a separate accelerator. You don't even have a point. Gay. Faggot. Moron.

>>106195690
I use it at work for our IPTV server. The deinterlacing is pretty good, at least good enough for all the SD channels. For the HD ones that need deinterlacing we use cuda bwdif/nvenc.

animefag too stupid to use chat

>>106199999
checked

>>106200000

>>106198831
Is picrel even libsvt? Is there a comparison to intel av1 and not nvenc hevc?
>>106199599
Sounds like a cool job anon

>>106195651 (OP)

you have to remember air lots used to have like fixed sync crts not mess any signalling like landing path radio

>>106195690
Hardware encoders are good for making a master encode out of davinci resolve, then doing software optimised encodes out of that

>>106201223
No it's a proprietary custom AV1 encoder using FPGAs. It's trying to bridge the gap between CPU and GPU video encoding. A hybrid video encoder maybe but the reason I posted is because the fast preset aurora1 seems to be on par with preset 8 libsvt.

I was able to finally hunt down a comparison where quality validation was done with quicksync AV1 but you should take it with a grain of salt as it's a 3 year old sample and missing tons of libsvt quality improvements that were added recently.

but yeah low bitrate and GPU video encoding just don't mix.

>>106202317
>I was able to finally hunt down a comparison where quality validation was done with quicksync AV1 but you should take it with a grain of salt as it's a 3 year old sample and missing tons of libsvt quality improvements that were added recently.
I like to use this: https://rigaya.github.io/vq_results/
some of the results are kinda fucky wacky (e.g. amd's h264 while very bad, from both my own testing and eposvox's, it's not nearly as bad as it's portrayed here) plus there are no gayming samples or anything like that and the reference that was used for the anime test is pretty much impossible to track down (or at least, i tried but failed, it's like an mv ripped from the files of some obscure as shit game or something like that) but overall it can give some valuable data (especially comparing generations of various encoders)

>>106195690
>tripbabby spews garbage
Thanks for smearing yourself.

>>106203638
I showed you my trusted quality validation source in >>106202317

Now show me yours.

>>106202317
>amd amf on par with nvenc
>intel quicksync leagues better than nvenc
yeah this data has something fucked going on

>>106203785
It's nvenc h264 not h265. Can't find epox vox data on nvenc AV1 but if it beats quicksync that would be pretty dope. libsvt preset 8 quality at best so I'd still recommend libsvt on a modern CPU.

>>106203880
>It's nvenc h264 not h265
...yeah, and i'm looking at the h264 results only.
>Can't find epox vox data on nvenc av1
just hop on the site linked in >>106203495 already retard

>>106204194
Sorry I trust epos QV more. Actually I plan on doing a QV thread for VP9/AV1 later on today with files/params used so if that interests you look out for that.

>no ffmpreg thread
fine i'll ask here since the turboautists have sperged the bread already
i often do lossless transcodes of shit for *use case i'm not going to expain*, why does ffv1 give me double the filesize and only 10% faster encode speed compared to x264 lossless?
x264 ultrafast is the same size as ffv1 while being 50% faster
from what i've seen ffv1 shoud be both more efficient AND faster than x264 lossless so what gives?
i'm using yuv444p for both