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

[Alex KAS]

Hello,
Well, kind of found the point. But first, Steven, thanks for pointing
out exact places where the parameters are set.
This place seems consistent.

What happens however, is that later, at some point (will write below),
upon the decision taking process the parameter
lookahead-threads
is set differently for different presets.

According to some sources I found it supposed to be that
lookahead-threads=threads/6, so in my case with 2 cores, 4 processor
threads (core i5), I should have 3/2*(logical.cores=4)=6 threads in x264
and then only 1 lookahead-threads
However, in my case, with all other parameters identical, I see in the
output debug info that for all presets BUT veryfast lookahead-threads=1
and in veryfast it is lookahead-threads=2

This is somehow in accord with
https://mailman.videolan.org/pipermail/x264-devel/2012-May/009354.html
where exactly the veryfast preset was used as an example in the
discussion. But that post does not specify explicitly that changes will
affect veryfast only. Moreover, it was 4 years ago ...

I see this inconsistent because there is no logic behind to benefit out
of 2 lookahead-threads on veryfast and go back to lookahead-threads=1 in
super/ultrafast.

Finally, I checked that when I set explicitly
-preset veryfast -lookahead-threads=1
I come back to normal sizes hierarchy in 33 out of 34 instances. Exactly
I mean, size of veryfast was always bigger then medium and always
smaller then ultrafast.

Moreover, for my videos, changing lookahead-threads from 2 to 1
explicitly I gained 0.9 percent in SSIM metric quality in average.

Thus, in my opinion, being a dev, I would stick to equal number of
lookahead-threads in all presets.
Perhaps 2 is not a good number on just 4-logical-cores system, like mine.

Again, the debug output and my experiment with an explicit
lookahead-threads specification proves I'm on the right track.

The corresponding piece of code is at:
http://git.videolan.org/?p=x264.git;a=blob;f=encoder/encoder.c;h=f733adf2d97a7398e676aa7a549b6eb0ee0e9a5a;hb=72d53ab2ac7af24597a824e868f2ef363a22f5d4#l1178

I do not immediately claim the code is incorrect. I stress that the
decision taken (lookahead-threads=2 only for preset=veryfast) seems not
well motivated.

Hope this explains my concern.

With best regards,
Alex




On 25.11.2016 22:05, Steven Walters wrote:
>> 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.
> 
> ?
> I don't see how this is a contradiction.
> I said there is a tendency for the filesize to get smaller with slower
> settings, which you've indicated with the data.
> but I did not say that this guaranteed to occur, because it is indeed
> NOT guaranteed to occur.
> (tendency does not mean 100% of the time after all.)
> 
> Though in reality, none of this is particularly related with the
> presets, which you are seemingly solely fixated on, but instead this
> is the behavior of CRF in general.
> But moving on...
> 
>>
>> Other way around:
>> Is it too complicate to check whether the part of the code converting
>> "preset" into really used parameters is written correctly, specifically
>> for veryfast?
>>
>> I would do it myself (it is c/c++/asm, correct?) given someone can guide
>> me up to some extent at least saying where is the relevant piece of code.
> 
> By all means go look for yourself, the presets are defined at [0],
> though you'd likely also need to compare against the defaults which
> are the "medium" preset, which are defined at [1].
> 
> These are fairly straight forward/simple, so this should not take one
> long to review.
> As the code indicates, "veryfast" does indeed use settings "that are
> in between" "superfast" and "faster", so does this satisfy your
> request?
> 
> In the end, this is a behavior that users familiar with CRF in x264 are used to.
> Also, we don't develop x265, so comparing against that feels like
> comparing apples to oranges.
> 
> [0] - http://git.videolan.org/?p=x264.git;a=blob;f=common/common.c;h=029f7b39348c8c538335641f18d7cbfd9e004bf5;hb=HEAD#l182
> [1] - http://git.videolan.org/?p=x264.git;a=blob;f=common/common.c;h=029f7b39348c8c538335641f18d7cbfd9e004bf5;hb=HEAD#l47
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> https://mailman.videolan.org/listinfo/x264-devel
>