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

[Clayton Macleod]

Another note on quality versus size.  This is true more often when you are
talking about the same encoder with similar or same settings other than
bitrate.  If you compare x265 with settings of xyz and bitrate of 5,000
Kbps to x265 with settings of xyz and bitrate of 10,000 Kbps then you can
safely assume that the larger file will be of better quality.  All else is
the same, but you've given it more bits to work with, so it should be
giving you better quality as a result.  But if you try comparing x265 with
settings of xyz and bitrate of 5,000 Kbps to x265 with settings of abc and
bitrate of 7,000 Kbps the answer may not be so simple.  And then when you
throw completely different encoders into the mix then it will probably
become impossible to know much of anything just going off the bitrates
involved because of how differently the different encoders can behave.  So,
to repeat in summation, bitrate can be a good indicator of quality if
you're talking about the same encoder with similar settings other than
bitrate, but it isn't always a good indicator if you're throwing other
variables into the mix, most particularly if you're talking about
completely different encoders.

For example, with some recent tests I've been doing with x264 and x265 I
have been using VMAF to compare all the different presets.  Here are all
the filesizes for a movie in 480p and 720p where all files in question are
the same quality according to VMAF.  They all have a VMAF score of 97, so
according to that metric they are all the same quality, but as you can see
they all vary in size quite a bit.  The green is x264 and the blue is x265.

[image: image.png]

So as you can see, this is a case where size is not a very good indicator
of quality.  They should all look the same, but each instance can have
quite a different bitrate from the next.  The difference lies in the
features used and settings used for those features.  And this is the same
encoder.  If I also threw NVENC into the mix there would be even more
variables, and it would perform quite differently from x264 or x265.

So when would size be a good indicator of quality if this data shows that
in this case it is not a good indicator?  Well, let's say for example I
took a look at all the different features the medium preset uses and all
the settings it uses for those features.  I could then manually write a
command line that uses pretty much all the same settings, but list them all
individually instead of using the preset, and then use different bitrates
for each test case.  This time with only the bitrates being different for
each test case then the bitrate would be an excellent indicator of
quality.  You have to look at the complete picture, not just one
component.  Will a 200 MB file always look better than a 100 MB file?
Probably not always.  It is probably a good bet, but it may be possible for
the 100 MB file to look better.  It depends. ;)


On Sat, Aug 6, 2022 at 11:20 AM Reindl Harald <h.reindl at thelounge.net>
wrote:

>
>
> Am 06.08.22 um 20:11 schrieb jatmvp ctf:
> > I thought quality goes in pair with size
> there *may be* some correlation *but* you have speed/quality/size to
> assign and can only chose two as you can only have two of cheap/quick/good
>
> you need a ton of cpu-usage to squeeze out the last bit of quality while
> a sloppy and fast run leads to a way larger output file with terrible
> quality
>
> ----------
>
> take as example MP3 with VBR
>
> it will have the same or even better quality with VBR than 320kbit -
> extreme example: why would you need 320kbit for 2 seconds of silence?
>
> or take a mono record - with joint-stereo and VBR it takes less than
> half of the size of CBR with to difference - "play the same on both
> channels" don't need the information twice
>
> and before someone cries: yes, VBR with maximum settings can sound
> better at complex parts where even 320kbit won't be enough because it's
> more evenly around the complex part which needs high bitrates and what
> your ear notices is un-evenly quality - headroom is the key - CBR don't
> have any
> _______________________________________________
> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 125588 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-user/attachments/20220806/394fcbfe/attachment.png>