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

Nicolas George nicolas.george at normalesup.org
Sun Jan 1 10:37:07 CET 2012


Mark's message yesterday on the users mailing list (
) 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

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

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.


  Nicolas George
-------------- 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/20120101/48453baf/attachment.asc>

More information about the ffmpeg-devel mailing list