[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption
michael at niedermayer.cc
Wed Mar 8 04:48:56 EET 2017
On Wed, Mar 08, 2017 at 01:41:38AM +0200, Jan Ekstrom wrote:
> 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:
As it is the code that uses the common parser is buggy
that is if a user specifies no-fast-pskip
its not disabled
in fact it does not even error out or give any warning
IIUC you want an implementation thats based on a common parser ?
can you write an implementation thats based on a common parser and
which works without bugs in corner cases ?
i think that should be possible but if iam missing something, please
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel