[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

Jan Ekstrom jeebjp at gmail.com
Wed Mar 8 01:41:38 EET 2017


On Wed, Mar 8, 2017 at 1:01 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> the fast pskip i mentioned yesterday
>
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params fast-pskip -vframes 15 -an ref-p.nut
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params no-fast-pskip -vframes 15 -an ref-np.nut
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264opts no-fast-pskip -vframes 15 -an ref-no.nut
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264opts fast-pskip -vframes 15 -an ref-o.nut
>
> ffd2c735cfb268d5f4291c2f6baab386  ref-o.nut
> ffd2c735cfb268d5f4291c2f6baab386  ref-p.nut
> f424075a964018aa83f98f2bf5ab2830  ref-no.nut
> ffd2c735cfb268d5f4291c2f6baab386  ref-np.nu
>
> it appears *fast-pskip has no effect in x264-params

Right, as I noted in my previous message, the custom dictionary
parsing code in there sets the value to "1" if a value is not
available. The API always expects a key and a value (even if a NULL
value would be valid for a boolean option).
So to emulate what x264opts is doing you would just set "fast-pskip=1"
or "no-fast-pskip=1". You can by this guess that fast-pskip is indeed
the default behavior during medium preset in libx264.

In my personal opinion I'm not sure this is worth it to have a Yet
Another Dictionary Parser inside libx264.c, esp. since
av_dict_parse_string() behavior is already the defining one in
multiple components where key/value lists are handled (you can see our
Doxygen for some sort of list of usage:
https://www.ffmpeg.org/doxygen/trunk/group__lavu__dict.html#gaca5ff7c251e60bd13164d13c82f21b79
).

>
> i have no idea if thats the only issue
>

Unless the very short code around it, or av_dict_parse_string is
globally bugged in some way, most likely all "issues" with x264-params
are due to the implicit value being set for key-value pairs without a
value.

> also to keep both x264-params and x264opts working you need just
> 1 line more than if you drop one. Its just one entry in the AVOption
> array to pass both to the same implementation
>

That is another alternative and at the very least would remove the
duplicated implementation which would be a positive step forward. For
some reason I would prefer only having a single option for this so
that there would be no questions regarding why the behavior changed
for x264opts with regards to implicit values.


Best regards,
Jan Ekström


More information about the ffmpeg-devel mailing list