On Wed, Mar 08, 2017 at 01:41:38AM +0200, Jan Ekstrom wrote: > On Wed, Mar 8, 2017 at 1:01 AM, Michael Niedermayer > <mich...@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 > ). 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 elaborate [...] -- 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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
