[x264-devel] preset veryfast always generates lower bitrate than veryslow. Why and how to fix?

Steven Walters kemuri9 at gmail.com
Fri Nov 25 14:33:08 CET 2016


On Fri, Nov 25, 2016 at 5:24 PM, Alex KAS <alex-kas at altaray.net> wrote:
>
>  Hi,
>
>  I can confirm that I consistently get the
> -preset veryfast
> generating even lower bitrate then
> -preset veryslow
>  I tried this with on many types of video and every time carefully
> verified that all parameters (surely including -crf) stay intact.
>  This at least contradicts the idea of presets and the corresponding
> explanations about them.
>  I cannot believe it is an expected behavior.
>  The expected and documented is the intention to maintain -crf while
> allow more (slow) or less (fast) compression for the same perceptual
> quality.

"documented"? documented where exactly?
CRF is well known to fluctuate in size, in either direction, when the
settings change.
i.e. when using slower options, there is no guarantee that the
resulting size will decrease
and when using faster options, there is no guarantee that the
resulting size will increase.

There is a correlation between the settings and size that has a
_tendency to occur_, but in no form is there any guarantee (causation)
about it when using CRF.
I don't recall anywhere in our codebase that this is officially
documented to be a mandatory causation.
If you want a particular resulting file size, use ABR.

In the end, CRF is only a "constant factor" for the _same input
material_ for the _same settings_, change the material or the settings
then "all bets are off".


>  My wish is not only to fix veryfast.
>  My wish is to check the integrity of the "preset" notion in all instances.
>  It is important at least to check that for any preset the specified
> -crf (and any other video/audio quality parameter) is maintained accurately.

What "notion" are you interpreting here?
So far it seems like this is primarily an issue of utilizing a
generalization as a standard (around CRF)...

>From looking at the tickets you linked to, you already received the
appropriate feedback about what the presets actually are:
presets are simply notions of how relatively long it will take to
encode, there is no implicit or explicit contract that they will have
a corresponding effect on the size.
Once again, there is a only a _generality_ in that using a slower
preset is _likely_ to get a smaller filesize (We do not state
guarantees about it).

need the encoded video fast? use a fast preset.
have all the time in the world? feel free to use a slower one.
it really is as simple as that.

-Steven


More information about the x264-devel mailing list