[FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?

[Phil Rhodes]

 Producing objective metrics of the performance of video codecs is notoriously difficult. Or at least it isn't - given enough access, you can calculate a signal-to-noise ratio through the codec, but that sometimes doesn't do a very good job. Wavelet codecs are sort of notorious for producing really good SNRs while subjectively looking much worse than other things that they numerically seem to outperform. Consider also the fact that many codecs are part of cameras and other hardware devices, where we often can't send them test data, and it becomes impossible to evaluate the codec in isolation (though it's quite possible to shoot test material and compare that).
That's not to argue with the idea that the codecs in graphics boards do a rather approximate job; that's clear from looking at the result, though it's a perfectly legitimate horse for a perfectly legitimate course.
P


    On Saturday, 6 August 2022 at 19:32:52 BST, Clayton Macleod <cherrytwist at gmail.com> wrote:  
 
 One thing I noticed when comparing x264/x265 to Nvidia counterparts is the
Nvidia encoder tended to get rather ugly in the chroma as you leaned
towards smaller files a lot sooner than x264/x265 would, and not by a small
margin.  During tests where I was using VMAF results to compare I could get
files from each encoder to have the same VMAF score but the Nvidia file
would look much, much worse.  Could even contain very nasty macroblocking
that nobody would overlook, not even laymen with no video encoder knowledge
at all because it was so bad and so obvious, but the x264/x265 file with
the same VMAF score would look way better.  Then I re-read the VMAF docs
again and noticed that it only examined luma, and I was surprised I missed
that the first time I had read through.  So the Nvidia encoder seemed to be
focused on luma quality a lot more than chroma, and the amount of
corner-cutting they were doing in the chroma department was glaringly
obvious.  I think for video game streamers it is a very nice thing to have,
an encoder that uses none of their CPU, but for nearly all other uses it is
probably going to be better to spend a bit more time doing a CPU encode, as
it is possible to get much better results with fewer bits.

On Sat, Aug 6, 2022 at 11:11 AM jatmvp ctf <justanotherteammate at gmail.com>
wrote:

> Thank you all for your responses!!! :)
>
> Thank you Gabri Shally, and I must say that I was both surprised and
> astonished too, about those quality score and size output.
> I thought quality goes in pair with size. I got quality 36 (higher is
> better, yup?) on libx265 and it looks better when I watch it, and 19
> (lower) hevc_nvenc. The size is smaller when achieving higher quality...
> Maybe this depends on many "static" scenes (where only little of picture is
> having non-zero spatial differentiation of picture) and the encoding
> algorithm indeed! Or CPU capabilities (I have quite decent CPU I think..)
> If so, I would then stick and always use the CPU version because of this
> 2-4x penalty of encoding time is nothing in comparison of output size and
> quality I get :) Good job and kudos for everyone who was involved in
> achieving this in ffmpeg code! :) Not only getting great output (metered
> for quality and data density), but also while low latency preparation on
> decoding is set up.
>
> It is probably related to some things Clayton Macleod said about encoders
> are not standardized as well as decoders are (and as I understood, they do
> not have to, so why :) ), the setup of nvidia encoder I not have made maybe
> (or not available on Windows platform nowadays - would find  ) with
> comments from Mick Finn (would read doc, thanks!) & Harald Reindl, and some
> issues about which David Stephen wanted to tell, but the response of the
> last FFMPEG User I've mentioned is not yet understood by me well I think,
> but still David thanks for your input and understood your emotions between
> OSS and closed /proprietary one.
>
> I use the msi manufacturer RTX 3080, supplied from a stable power source
> with 3 independent power lane sockets, so should be okey. Should I attach
> the version of GPU always here? :)
> Sorry for not mentioning it earlier, I read some messages here, but I have
> a lot of knowledge to assess :)
>
> I take your point Clayton Macleod, and thanks for elaboration on this. I
> think that was also what Harald Reindl wanted to tell me but I was not
> knowing about nVidia encoder goal "in mind". Must rethink and would test +
> query if have other ideas/results/benchmarks (maybe helpful for someone) to
> share.
>
> Also, thanks Harald Reindl for sharing your look on my interpretation and
> ease on my (not to-the-point) valid assumptions.
> Of course, I agree implementation (code) is highly different as for CUDA
> cores and the whole GPU ecosystem processing is done differently than on
> CPU + RAM + MB, and they are different in architecture, silicon et al.
> Would learn more before asking next things.
>
> btw. I seen many of you run it not with cuda nor dxva2.
> Mine available are "Hardware acceleration methods: cuda dxva2 d3d11va"
> Is that bad? I cannot find nvenc/nvdec there
>
> Any sources I should read from begin to end you think? Or some ffmpeg code
> source part?
>
> Really appreciate any further and presented help! :)
>
> sob., 6 sie 2022 o 13:21 Gabri Shally <gabri.ns at gmail.com> napisał(a):
>
> > on both command, you didn't give any option about bitrate or quality
> > target, so the implementation may freely choose those.
> >
> > if you see output near the end, nvidia give quality of 19 while libx265
> > give 36, so the size would be different wildly.
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-user at ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
> >
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>


-- 
Clayton Macleod
If no one comes from the future to stop you from doing it, then how bad of
a decision can it really be?
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".