[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170308/c4a858c6/attachment.sig>