[FFmpeg-devel] [PATCH] opt: implement av_opt_set_from_string().
stefasab at gmail.com
Sun Sep 2 11:52:13 CEST 2012
On date Friday 2012-08-24 12:45:54 +0200, Nicolas George encoded:
> L'octidi 8 fructidor, an CCXX, Stefano Sabatini a écrit :
> > Well I still can foresee some cases where this is not the case
> > (e.g. real person names as keys - admittedly not very realistic).
> I think we can exclude that case.
> > 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").
> There are still a lot of chars that can serve as context separators without
> risking any conflict with reasonable key=value and field separator: '/' and
> '.' are quite obvious choices, '>' is used by CSS, etc.
> > If you consider the additional complexity not worth the feature,
> I think so, but I would like some outside advice. Maybe look at the current
> code of parse_key_value_pair, and try to guess in advance where various
> cases of invalid input will fail and the error message that will result: if
> you get it wrong, then the code is probably too complicated :)
I'm no good at doing that. What I do in these cases is to write a test
which covers most sane and pathological cases, and check how it
behaves. Again, if you don't want to do that I can adopt the patch and
work on it myself.
> > 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.
> Of course.
> Also, there is a balance to maintain in reserving chars for key names: if we
> reserve too many chars, that limits the possibility of separators, but if we
> reserve too few chars, we may regret it when implementing some strange
> namespace thing with options.
As a starting point: alphanumerical chars, "_", "/", "." might be
reserved for keys, so they should never be used as separators (should
we allow spaces in keys)? Note that we currently use only
alphanumerical chars and "_" in our codebase.
> For that, I must wonder under what circumstances an application may want to
> use other characters as separators.
You may need to nest a list of settings inside another list, so you
try to avoid to use certain characters in order to avoid escaping.
Now suppose you want to add some lavc settings. Since you already have
"," and ":" as special characters you don't want to reuse them as
separators in order to avoid escaping. So you set "&" as separator.
FFmpeg = Foolish Fast Mythic Puritan EnGine
More information about the ffmpeg-devel