On Tue, Mar 07, 2017 at 10:08:59AM -0900, Lou Logan wrote: > On Tue, 7 Mar 2017 04:24:23 +0100, Michael Niedermayer wrote: > > > its a long time ago but i faintly remember that the option you are > > about to remove worked while the one remaining had bugs > > Can you provide a reproducible case? I will try as well.
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 i have no idea if thats the only issue 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 > > > also this would break scripts > > I've never liked this argument. Scripts could have been broken when > we removed libfaac, libstagefright, libquvi, etc but I don't recall any > users complaining. > Scripts can be fixed: we shouldn't be beholden to > alleged, random, moldy, old "scripts" in the ether, otherwise we'll scripts as in examples all over the net, mailing list acrhives blogs and so on. they can be updated but not by the people using them and in many places also not by the authors who wrote them. also testcase we have on trac can break when things get removed > never clean up anything. If users want to write-it-and-forget-it they > can just use a release branch. cleanup is good and i support it, and theres a lot of code we have that would benefit from cleanup. > > There is much inertia facing attempts to tidy up the code, and I > believe the strong expectation of encountering this often prevents > people from even trying. There is inertia facing removing API, removing features, breaking users of FFmpeg, ... cleanup is much more than that [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel