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

[Alex KAS]

On 25.11.2016 14:33, Steven Walters wrote:
> 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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
> 

Hi,

Thanks, Steven, for your prompt feedback.

Let's put things straight. I suspect a mistake in the code. Ok?

I encoded literally 34 videos in a raw. All the time the command line
was identical (-crf 22, etc) apart from filenames and the -preset setting.
Every time I got that
veryfast
creates a file of the smallest size. Even less than
placebo or veryslow

This just statistically contradicts your statement:
> 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.

It must be enough for 34 clips of different scenic nature and length to
maintain mentioned by you tendency.
It is maintained for all presets but veryfast. veryfast is always with
the smallest output. Always!
One example is like this (always -crf 22):
23011486 out4raw18uf.bin [-preset ultrafast]
13290851 out4raw18sf.bin [-preset superfast]
 8497399 out4raw18vf.bin [-preset veryfast] !!!
10693533 out4raw18fr.bin [-preset faster]
11290350 out4raw18f.bin  [-preset fast]
10621999 out4raw18m.bin  [-preset medium]
10976305 out4raw18s.bin  [-preset slow]
10487295 out4raw18sr.bin [-preset slower]
 9624410 out4raw18vs.bin [-preset veryslow]
10026459 out4raw18p.bin  [-preset placebo]
And this is THE characteristic example, i.e. standard.

Now, assuming there is a mistake, I suggest to devs to lookout whether
other places of code, setting parameters for other presets, are fine.

As a sidenote, x265 encoder works with the same videos in what I name
"expected" way. filesizes for a given crf indeed tend to decrease with
lowering speed (increasing time) for encoding.
However, I cannot use x265 for browser compatibility reasons. I must use
a 264 encoder.

Thanks and best regards,
Alex