[FFmpeg-devel] [PATCH 01/14] lavfi: add common code to handle options parsing.
nicolas.george at normalesup.org
Sun Mar 17 14:57:16 CET 2013
Le septidi 27 ventôse, an CCXXI, Stefano Sabatini a écrit :
> 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).
I considered that briefly, but I did not go that way because I believe it
may be more likely to end up in an ABI compatibility hell.
> 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.
Note that the shorthand field in my patch is in the private part of the
AVFilter structure: removing it would not be considered an API or ABI
Another point: lavfi is different from the others AVOption users because it
implements its own parser (parsers, even) from strings. Codecs, formats,
etc., only see options as a finished business, they do not care whether they
came from command line with the dash-option syntax or from a GUI.
In other words, the shorthand list makes sense along with the
"init(char *args)" method, and only filters have it.
(As a side note, I am currently considering reworking buffersrc and -sink to
allow setting the parameters using av_opt_set rather than with the argument
string or the opaque structure. Other filters may benefit from the same
changes, and that would allow, e.g. GUI to build filter graphs. Filters who
adapt their number of pads dynamically will not work that way yet though.)
> In conclusion a locally optimal solution could be acceptable as long
> as it doesn't hinder too much the work towards a more generic
I completely agree.
> Will reply in a separate mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel