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

Nicolas George nicolas.george at normalesup.org
Fri Aug 24 12:45:54 CEST 2012

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 :)

>								   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.

For that, I must wonder under what circumstances an application may want to
use other characters as separators.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120824/7f0b8267/attachment.asc>

More information about the ffmpeg-devel mailing list