[FFmpeg-devel] Filters & AVOptions

[Pavel Koshevoy]

On 4/11/2013 11:29 AM, Clément Bœsch wrote:
> Hi,
>
> Some little comments about what's been done these last hours about the
> filters and AVOptions.
>
> But first, some little story/context. A while ago, we introduced the
> shorthand for filters. Basically, the ability to have "c=3:a=1:b=2" or
> "1:c=3:b=2" or "1:2:3" and use internals/helper to auto parse these
> options to initialize the local filter context. The order of the
> short-hands (the parameters without a key) was defined in each filter with
> something like:
>      const char *const shorthand = {"a", "b", "c", NULL};
>
> A few days ago though, the fork introduced a similar feature making use of
> the filters' AVOption options declaration instead. This has some
> advantages, and some drawbacks over our own solution. Anyway, it was
> decided to switch to this new shorthand system (because the new system
> will allow some dictionary init which might be relevant). For the users,
> not much things should change.
>
> Most of the filters are now compatible with this new system: the filters
> have either a priv_class/avoptions/etc or nothing if they take no
> parameters.
>
> The problem for the remaining filters is mainly that they can't use ':'
> freely anymore: it's the separator used for separating options, and the
> parsing has completely moved to avfilter internals. Basically, filters can
> not receive a string as initializer anymore (the idea is to have a
> dictionary init form only). Various temporary solutions are available to
> deal with this problem, the main one being a ':'-to-'|' replace in the
> compat layer (see lavfi/avfilter.c:avfilter_init_filter). Then the filter
> only uses '|' as an item separator (most of the time the abuse of ':' was
> to separate a list of items).
>
> We've dealt with most of the filters, but some are remaining and need to
> be updated ASAP before the next incoming evil wave. Here is the list and
> the problem we have to handle (this list is from
> avfilter.c:filters_left_to_update):
>

>    atempo
>      Might be problematic because of the process_command system

Maybe it's best to drop process_command from atempo? I am not aware of 
any code that executes that anyway.

Pavel