[FFmpeg-devel] [RFC] BSF list API

[Marton Balint]

On Sat, 11 Jun 2016, Nicolas George wrote:

>> Instead of adding a totally new API, I suggest to use a "container"
>> bitstream filter called 'list', which will instantiate the "child" bitstream
>> filters and pump the packets through them.
>>
>> Thanks to the N:M nature of the new BSF api, this should be achievable, and
>> we can completely hide for the API user if we are using a single bitstream
>> filter, or a chain (list) of several bitstream filters.
>
> I had the same idea, and it is not without merits, but I no longer think it
> is the best course to go.
>
> The main merit of the idea is to keep the API identical, and it is mostly
> useful for compatibility with the fork. Since this is no longer a primary
> goal, other considerations must prevail.
>
> As I observed benchmarking the null bsf, the overhead of a dummy bsf is not
> entirely negligible, mostly due to a few mallocs. Better avoid it if
> possible.

Maybe I am missing something, but as far as I see the alloc is due to the 
alloc in ff_bsf_get_packet. We could create a similar function 
ff_bsf_get_packet2(AVBSFContext *ctx, AVPacket *pkt) which does not 
allocate a packet but simply moves the ref to pkt. Then this can be called 
with the output packet pointer, so no allocation will be requried. And 
this function can be used for performance sensitive places instead of the 
original.

>> The mentioned 'list' bitstream filter could have an AVOption string
>> parameter called list which it can parse on init to create the bitstream
>> filter chain. The list string would follow the ffmpeg bsf list syntax:
>> filter1[=opt1=str1/opt2=str2][,filter2]
>
> For that, I say no: it must have a proper API. We can have a parsing
> functions for user-provided strings describing list of filters, but nowadays
> most filter lists are created by applications or the library, and for that
> we do not want a round-trip to a string with all the problems that entails
> (quoting, memory allocation or arbitrary limits), this kind of madness is
> already present in too many places.
>
> The API itself could be only:
>
>    ret = av_bsf_list_append(list, filter, &ctx);
>
> The append functions returns the newly created filter, so we can set options
> on it if necessary. Then the filters are inited, either by calling
> av_bsf_init() on each of them or by having av_bsf_list_init_all(), either
> solutions has merits of its own.
>
> Note that this solution can work with a container filter too. I would prefer
> that list is its own dedicated type, maybe AVBSFList, but if it is an
> AVBSFContext, av_bsf_list_append() can assume it is a container filter and
> access its private structure.

I think we need to support both ways to configure the bsf list. What the 
tee muxer, or ffmpeg.c would use, is the text based configuration, 
therefore it's worth adding the capability of parsing such lists.

So what we need, on top of what I proposed, is an additional API what you 
proposed (av_bsf_list_append), and which can be used to add filters to the 
list, after we allocated the list filter, but before we initialized it.

This way the user can decide which configuration method - API based 
or text based - he will use.

Regards,
Marton