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

[Richard F]

I tend to agree with Alex about the "veryfast" preset

I have encoded thousands of videos of various types from home movies to
HDTV and "veryfast" is most definitely a sweet spot in terms of
size/encoding time, which is why I use it for archiving CCTV footage.

I can't be sure whether using slower presets produces better results at
the same crf (the stated likely outcome), but they certainly go slower.

Just my 2 cents


On 25/11/2016 15:04, Alex KAS wrote:
> 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
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel