On Mon, 7 Aug 2017, Michael Niedermayer wrote:
On Sun, Aug 06, 2017 at 10:37:35AM +0200, Nicolas George wrote:
L'octidi 18 thermidor, an CCXXV, James Almer a écrit :
What do you mean? What i suggested would be done each time an option is
removed or added anywhere but at the end, both of which afaik are
uncommon cases.
It's not something that requires a rewrite of the current codebase.
I mean that since I consider the break bearable (somebody upgrades a
piece of software, they MUST test the scripts that depend on it, and
fixing the issue once and for all is easy), I am not willing to spend my
time implementing (and testing, for this kind of thing that takes time)
the deprecation-warning-and-backward-compatibility dance.
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
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.
Please correct me if iam wrong, but isnt all that is needed to just
not remove the options from the AVOption array from the tiny number
of filters affected?
Or declare the tiny number of moved/changed options as removed/not
supported in shorthand notation.
Yeah, what is needed for compatibility? Only a single AVOption line, or
additional code as well?
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
