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

[Stefano Sabatini]

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.

For example:
can_humans_dye_when_connected:yes,elected_users:"Neo",smith_agent_process_respawn:yes,have_ghosts:yes

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.
 
can_humans_dye_when_connected:yes,elected_users:"Neo",smith_agent_process_respawn:yes,have_ghosts:yes,lavc_conf:s=qcif&pix_fmt=yuv420p
-- 
FFmpeg = Foolish Fast Mythic Puritan EnGine