On Mon, 13 Jun 2011 01:43:07 +0200, Stefano Sabatini 
<[email protected]> wrote:
> > + * @param[in] name The name of the option to look for.
> > + * @param[in] unit When searching for named constants, name of the unit
> > + *                 it belongs to.
> > + * @param opt_flags Find only options with those flags set (AV_OPT_FLAG).
> 
> > + * @param search_flags A combination of AV_OPT_SEARCH_*.
> > + *
> > + * @return A pointer to the option found, or NULL if no option
> > + *         has been found.
> > + *
> 
> > + * @note Options found with AV_OPT_SEARCH_CHILDREN flag may not be
> > + * settable directly with av_set_string3. Use special calls which
> > + * take an options AVDictionary (e.g. avformat_open_input() ) to set 
> > options
> > + * found with this flag.
> 
> This restriction is a bit clumsy and is introducing an asymmetry
> between setting and getting operations. What about:
> av_opt_set(..., int search_flags)?
> 
> Anyway if this is a limitation of the current av_set_string3() there
> is no way to block this patch, but this problem should be analyzed
> before for avoiding future API fixes.

Well that's the main point of the new API ;)
The problem is that at the point when you want to set the options,
all those private contexts don't exist yet, so I see no way to make
this work with av_set_string.

> 
> (BTW I don't know if related, note that currently ffprobe+private
> options doesn't work because of the way AVFMT_PRIV_OPTIONS is handled.)

No idea, we didn't merge this.

--
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to