[FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

Nicolas George george at nsup.org
Mon Aug 7 12:03:51 EEST 2017


> >Lets take a step back and look at this
> >
> >There are some rarely used options in multi input filters like
> >overlay which break.
> >Noone even noticed except me
> >
> >And you propose to declare the most used syntax from every filter
> >unstable.
> >
> >This just doesnt add up, its like shooting the patient in the head as
> >a treatment for a cold

No, that is like telling the patient they need to take their antibiotics
until the last day of treatment and not stop once they feel better,
because they risk getting a pneumonia. Which is technically true, only
very unlikely.


Le decadi 20 thermidor, an CCXXV, Marton Balint a écrit :
> Do you like this text better?
> 
> Future evolutions of filters may require inserting new options or changing
> their order, especially for the non-essential options, and while we make
> reasonable effort to keep the order so the options given without their name
> would not break, sometimes that is not feasable. Therefore users should
> generally favor the @var{key=value} notation, or refer to the Changelog file
> which should contain such incompatible changes.

This is obviously the intent, but I do not think that the documentation
is the place to make that kind of intent statement.

> Yeah, what is needed for compatibility? Only a single AVOption line, or
> additional code as well?

Additional code as well. Not a lot, but still some. And testing. An
exponential number of cases.

I do not intend to do it.

We have already wasted more time than all the users combined will spend
typing "x=", "y=". Seriously, people !?!

Now, to all that stated a negative opinion about this:

I have in the queue a patch series that changes the options in a minor
way, but at the same time fixes bugs and long-standing limitations of
lavfi and makes the code more robust and cleaner.

Do you :

1. propose to implement and test compatibility options yourself?

2. own up you are blocking these enhancements?

3. accept the series and the breakage?

I will consider the absence of reply in a reasonable time as "4. do not
care".

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170807/4cb6d76e/attachment.sig>


More information about the ffmpeg-devel mailing list