[FFmpeg-devel] [PATCH] Implement options parsing for avfilter filters

Michael Niedermayer michaelni
Sun Apr 19 23:54:57 CEST 2009


On Sun, Apr 19, 2009 at 11:41:29PM +0200, Stefano Sabatini wrote:
> On date Sunday 2009-04-19 20:24:13 +0200, Michael Niedermayer encoded:
> > On Sun, Apr 19, 2009 at 06:37:13PM +0200, Stefano Sabatini wrote:
> [...]
> > > Mmh, do you mean for key=val pairs?
> > > 
> > > What about to use the '?' to separate filter from params?
> > > 
> > > filter?key1=val1:key2=val2:...:keyN=valN
> > > 
> > > The '=' for key=val pairs seems the more natural choice.
> > 
> > '=' is not a symbol that needs escaping in the parameter string
> > 
> > only terminating symbols and \ ' need escaping
> > 
> > scale=key1=val1:key2=val2
> > is not ambigous
> > 
> > in that sense i dont think much escaping should be needed
> 
> Yet maybe such a syntax:
> filter?key1=val1:key2=val2:...:keyN=valN

i like to repeat, the = does not need escaping and the syntax is
filter=key1=val1:key2...


> 
> may simplify the graphparser parsing, and also drop the need for
> escaping the = chars.
> 
> [...]
> > > +char *av_consume_string(const char **buf, const char *term)
> > 
> > the function name is no good
> > unescape, get_token ...
> 
> av_get_token()?

maybe

[...]

> [...]
> > > +/**
> > > + * Parses the options in opts.
> > > + *
> > > + * opts contains a list of "key=value" pairs separated by the ":"
> > > + * chars. The '=' and ':' chars can be escaped using the '\' char.
> > > + *
> > > + * For each key/value pair found, stores the value in the field in ctx
> > > + * that is named like key. ctx must be an AVClass context, storing is
> > > + * done using AVOptions.
> > > + *
> > > + * @return 0 if successfull, a negative number otherwise
> > > + */
> > > +int avfilter_parse_options(void *ctx, const char *opts);
> > 
> > no, av_ not avfilter, this code is not a filter or in any way
> > related to avfilter beyond just being using by avfilters at first
> 
> This suggests a better name for the files, parseutils.[hc], but then I
> wonder lavfi is not the better location for them.
> 
> And since they also require opt.[hc] then the better place looks lavc.

ive no objection to putting them in lavc, but this requires them to be
public API and this means it will take more time to approve because
changing public API later is painfull

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090419/13ce58e0/attachment.pgp>



More information about the ffmpeg-devel mailing list