[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption
michael at niedermayer.cc
Wed Mar 8 01:01:43 EET 2017
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel