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 ). > > 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
