On Sat, Aug 05, 2017 at 11:42:06AM +0200, Nicolas George wrote:
> Signed-off-by: Nicolas George <geo...@nsup.org>
> ---
> doc/filters.texi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 7e5a9a625a..886cd5a7e8 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -161,6 +161,11 @@ follow the same constraints order of the previous point.
> The following
>
> @end itemize
>
> +Future evolutions of filters may require inserting new options or changing
> +their order, especially for the non-essential options, and that would break
> +options given without their name. For that reason, uses that require
> +stability should favor the @var{key=value} notation.This is ambigous and if interpreted litterally then even a scale=320:240 would no longer be guranteed to work but would require scale=width=320:height=240 to be used. the shorthand is widely used and convenient IMHO declaring it _all_ unstable would be a mistake also iam thinking that we should either accept the option order we choose when initially adding a filter and try to maintain compatibility whenever that is possible. Or specify exactly for each filter in the code which options are allowed in shorthand and then also not accept options beyond that if accessed through shorthand That way anything that works will contine to work and one cannot mistakly write a script that uses unstable shorthand options [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
