[FFmpeg-devel] [PATCH 01/14] lavfi: add common code to handle options parsing.

[Stefano Sabatini]

On date Sunday 2013-03-17 13:39:14 +0100, Nicolas George encoded:
> Le septidi 27 ventôse, an CCXXI, Stefano Sabatini a écrit :
> > Could you elaborate on this (especially about the last point)?
> 
> There are currently a few filters that implement a parser more complex than
> options parsing. Some of them use a syntax that is similar to options
> parsing, so the solution of transforming the argument into a single string
> option with shorthand will lead the user into escaping hell.
> 

> I am thinking of af_pan in particular: it implements the
> "out_channel=in_channels:out_channel=in_channels" syntax, but out_channel
> depend on the requested layout, and therefore can not be stored as options;
> furthermore, the = can become a <, and it has a different semantic.

I see.

> > My medium term plan is to make all filters support options, so we can
> > simplify and generalize option handling, for example to support a
> > filter(foo="1", bar="string") syntax.
> 
> That is an interesting plan, and I think I support it in principle.
> 
> > Yes, but it is weird to enable option parsing *only* when shorthand is
> > defined. That said, I'm not against this if it is meant as an
> > intermediary step towards the final end.
> 
> Ok, let us consider this a starting point.

I wonder if we should move shorthands to AVClass, where it would make
more sense (since shorthands are meaningful just when there are
options, and thus a class).

If we add shorthands to AVFilter and we move shorthands to AVClass,
then we have to deprecate them in AVFilter, so overall adding them to
AVClass would be the globally shortest path choice.

OTOH this would require more work on the framework and more testing
(changing opt, and probably fix globally all filters with options in a
single commit). This could be possibly done with an experimental
branch on which several developers merge their work, like it was done
for TEM (The Evil Merge).

In conclusion a locally optimal solution could be acceptable as long
as it doesn't hinder too much the work towards a more generic
solution.

> Any technical comments on the patch series?

Will reply in a separate mail.
-- 
FFmpeg = Frenzy & Fantastic Merciless Perfectionist Enigmatic Gem