[FFmpeg-user] Why ffmpeg libx265 generate way smaller files than cuda/nvidia based one?
cherrytwist at gmail.com
Sat Aug 6 03:57:35 EEST 2022
What you have to remember is, things like H.265 and H.265 are standards for
DECODING. They're not standards for encoding. Not really. Your encoder
can do whatever it likes so long as a decoder that meets the standard can
correctly handle the data stream. Encoders can take many different roads,
and software encoders such as x265 can have very different goals from
hardware encoders like Nvidia's, and can handle things quite differently
based on those goals. In general, hardware encoders tend to take shortcuts
to mean real-time goals, whereas with a software encoder you are probably
not going to be as worried about how long the job takes. The hardware
encoder speeds up many things, but some of that optimization for runtime
results in lesser quality.
Nvidia's H.264 and H.265 encoders are fast and move the work away from the
CPU, but they also cut corners, and do not offer as much tweaking
capability, nor as much quality. The H.265 data streams coming from
Nvidia's encoder can look pretty good, but it is never going to give you as
much quality as something like x265 can if you set x265 to give better
quality output. It can and will give much better output than the hardware
encoder if you tell it to. The hardware encoder is only capable of so much
quality, though, and if you set it to give you the absolute best it is
capable of the result is still not as good as what you could do with x265
because it has more options and larger range for setting some of those
options. It is a performance trade-off. The hardware encoder is faster at
what it does, but what it does is not better, or even as good. Remember,
what the Nvidia H.265 hardware encoder does is not the same as what the
software encoder x265 does. They're doing different work in different
ways. The main shared goal there is to provide data streams that an H.265
decoder knows what to do with, but how they get there is very, very
different. You don't have as many settings you can tweak or as large of a
range of adjustment for those settings. It is restricted and compromised
so that it can run as fast as it does within a certain budget of
transistors. Software has no such limitation. Software is only limited by
how much CPU and RAM you want to throw at the problem. In hardware the
goal is to get away with providing a certain level of quality while using
only a certain amount of silicon to get there.
What I really wish Nvidia would do is give us "x265 slow" preset or better
quality in silicon. That would be much more useful for more people. The
quality of their current encoders is pretty good, but not great, and is
really targeted at certain uses. Probably most targeted at gaming
streamers, really, as that's how they seem to market it. But even that
would benefit from a better implementation, at least as far as quality
goes. It certainly already meets a certain level of quality while
offloading the work from the CPU. It certainly could be better, too.
On Fri, Aug 5, 2022 at 12:02 PM jatmvp ctf <justanotherteammate at gmail.com>
> Maybe my question is not correct. If both encode H.265 but I thought the
> performance ability (to create compression ratio) should be the same or at
> least comparable.
> That means CUDA version is only for some purposes and traditional open
> libx265 version for others? I guess, the CUDA is only for streaming, but
> then the decrease size of frames ( so increased compression ratio) to
> produce fast
> Harald, could you elaborate about those because I am really excited to know
> about it. Maybe I have compiled something wrong. I've been looking at it
> from yesterday so maybe I missed something in documentation :)
> Best regards.
> pt., 5 sie 2022 o 18:38 jatmvp ctf <justanotherteammate at gmail.com>
> > Different implementation of same standard should not behave way different
> > I assume, or not have same features or performance (at least).
> > Could you describe a little more or at least give source?
> > What are you suggesting by different implementation exactly then?
> > I guess from your short message that CPU is OK and nVidia's is bad,
> > - "it is different" but for me it is not metrics when you not give facts
> > pt., 5 sie 2022 o 17:46 Reindl Harald <h.reindl at thelounge.net>
> >> Am 05.08.22 um 17:02 schrieb jatmvp ctf:
> >> > I have problem with understanding why my ffmpeg with nVidia features
> >> > v:c hevc_nvenc) generate way larger file in comparison to libx265
> >> because it's a different implementation
> >> _______________________________________________
> >> 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
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
If no one comes from the future to stop you from doing it, then how bad of
a decision can it really be?
More information about the ffmpeg-user