[FFmpeg-devel] [PATCH] opt: implement av_opt_set_from_string().

Stefano Sabatini stefasab at gmail.com
Fri Aug 24 12:16:46 CEST 2012


On date Friday 2012-08-24 01:14:32 +0200, Nicolas George encoded:
> Le quartidi 4 fructidor, an CCXX, Stefano Sabatini a écrit :
> > I'm not sure if we should drop the possibility to specify
> > separators. Indeed while we're not using the feature, it could be
> > useful to the application layer (and we may need to specify different
> > option separators in different contexts, e.g. "," for protocol
> > options).
> 
> The thing is that preserving the quoting rules while allowing to set the
> delimiters makes the code very clumsy.
> 

> It would make the code much simpler if we decide that the key can not be
> escaped, and has a limited length for that matter. Since the key is actually
> the name of an option, it never needs to be escaped, to contain special
> characters or to be overly long, so this is in no way crippling the
> features.

Well I still can foresee some cases where this is not the case
(e.g. real person names as keys - admittedly not very realistic).

Also the keys might be used in different contexts
(e.g. "bikeshed:color=pink", depending on the context/separators
adopted this might be parsed uncorrectly if not quoted like
"'bikeshed:color'=pink").

If you consider the additional complexity not worth the feature, then
we should at least define and document (and ideally check at runtime)
which are the limitations on the key names, so that the user can
choose separators with the guarantee that parsing will be correct.

For example if we require that the option key names must only contain
ASCII alphanumeric chars and underscore, the user will not be admitted
to use "_" as key-val separator (and the parsing utility may spot this
at run-time).
-- 
FFmpeg = Fast and Fabulous Multimedia Peaceless Erratic Gadget


More information about the ffmpeg-devel mailing list