[FFmpeg-devel] Filters & AVOptions

Paul B Mahol onemda at gmail.com
Thu Apr 11 20:31:29 CEST 2013


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.


More information about the ffmpeg-devel mailing list