[FFmpeg-devel] [RFC] lavfi: automatic buffer ordering

Michael Niedermayer michaelni at gmx.at
Mon Jan 2 04:13:24 CET 2012

On Sun, Jan 01, 2012 at 10:37:07AM +0100, Nicolas George wrote:
> Hi.
> Mark's message yesterday on the users mailing list (
> http://ffmpeg.org/pipermail/ffmpeg-user/2011-December/004045.html
> ) has shown that there may be actual problems when filters output frames
> unasked (like split does) while the other end is not capable to deal with it
> (like overlay; it is not a coincidence if it happens mostly with filters
> with more than one input or output).
> In this example, the filters enter an endless loop of one asking a frame on
> one link and the other sending one on the other, eating all stack and heap
> space.
> The problem can be easily fixed by inserting a fifo filter at the adequate
> place; actually, it is the whole purpose of the fifo filter. I believe it
> would be better if it was done automatically.
> For that, I have the following proposal, that I intend to implement, but I
> would like to have some feedback before:
> struct AVFilterPad {
>     ...
>     unsigned flags;
> };
> /**
>  * The pad is safe with regard to asynchronous pushes.
>  * For output pads, that means that it will only push a buffer (start_frame
>  * or filter_samples) as a result of a request.
>  * For input pads, that means that it can accept a buffer at any time,
>  * regardless of whether it has requested it.
>  * If an unrequested buffer is pushed on a pad with this flag cleared, it
>  * will be queued until the appropriate time.
>  */
> Note 1: I chose this polarity for the flag so that pads where the flag was
> forgotten or not yet added will be considered unsafe by default.
> Note 2: with this semantic, a simple one-to-one filter like scale will have
> a safe input and an unsafe output. Therefore, the combination "safe input +
> scale" will have its output unsafe even though it is actually safe. I
> believe it does not matter much.
> As for the implementation, rather than having the filtergraph building
> process automatically insert fifos, I believe it is simpler to add the
> proper checks and queuing near the end of avfilter_start_frame and
> avfilter_filter_samples, and the start of avfilter_request_frame and
> avfilter_poll_frame.
> Note 3: if it gets implemented this way, then the fifo filter becomes
> trivial. The queuing logic in astreamsync and amerge gets a lot simpler too.

I like your solution.

maybe a
could be added
this way all filters with unknown saftey could then trivially be found
with grep


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120102/eb08fb89/attachment.asc>

More information about the ffmpeg-devel mailing list