Le primidi 21 prairial, an CCXXIV, Marton Balint a écrit : > My GSOC student Jan is working on improving the tee muxer, and as a side > project he is also working on converting the tee muxer to the new BSF API. > > I have checked his WIP patches, and it seems to me that developing some API > which we can use for BSF chains would be really useful not only for the tee > muxer, but for a lot of other places (e.g. ffmpeg.c) as well.
I wholly agree. I thought I suggested it already.
> 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.
Having a dedicated API, and more specifically a dedicated structure type,
also makes for cleaner function calls for the functions that manipulate the
list.
> 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.
> The list bitstream filter with and empty list can also work as the null
> bitstream filter already discussed on this mailing list.
Or the other way around: the null bsf is only useful in order to use the
same code path when there is nothing to do. If we replace the singe bsf API
with a list API, then we do not need the null bsf at all.
One of the benefit I see is that we can design the list API so that it does
not cause the overhead I mentioned earlier. For that to work, it needs to
take ownership of the AVPacket structure itself, not just its contents, but
that does not seem to hard to achieve.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
