[FFmpeg-devel] Filters & AVOptions

[Pavel Koshevoy]

On 4/11/2013 12:31 PM, Paul B Mahol wrote:
> On 4/11/13, Pavel Koshevoy <pkoshevoy at gmail.com> wrote:
>> On 4/11/2013 11:29 AM, Clement Boesch 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.
> Lets just drop everything, so Michael could merge with ease.
>

I am sorry, I can't tell if you are being sarcastic or not.  What I 
meant is -- if process_command in atempo is not exercised, then why keep it?

     Pavel.