[FFmpeg-devel] [PATCH 3/5] ffmpeg: flush and drain video filters.

Nicolas George nicolas.george at normalesup.org
Sun Mar 11 11:10:44 CET 2012


Le duodi 22 ventôse, an CCXX, Michael Niedermayer a écrit :
> avfilter was designed to handle multiple inputs and outputs from the
> begin so iam certainly interrested to hear in what cases this doesnt
> work currently

Consider the following command:

./ffmpeg_g -i some_video -vf 'split [out], fifo, nullsink' some_output

but before you try it, make sure you have severely limited the memory
consumption¹.

The problem is that as frames are requested on [out], split will send them
to fifo too, but nullsink will never request them: they accumulate in fifo.

Of course, both fifo and nullsink are silly here, but it could be something
useful, like stats_sink, and some piece of filters that needs to be
protected by fifo.

The same problem happens if nullsink is a second output: if we drain one
output until it is exhausted, frames can accumulate in the other one, but if
we drain non-recursively, we will not notice that fifo is blocking data.

The crux of the problem is that filters need to help regulating the traffic,
and that is precisely the opposite of what fifo does. We need to make sure
that fifo is never necessary, and make it go away. For that, we need to
observe very carefully all filters with several inputs to check that they
will not recurse (vf_overlay, I am looking at you) indefinitely.

(Also, for that reason, I withdraw my proposal of adding a flag telling if a
filter is safe to push a frame it has not requested: all filters need to be,
or they will cause traffic jam.)

If this is achieved, I believe data will flow correctly inside the filter
graph, and we will only need to worry about what happens at inputs and
outputs. And that part is easier.


1: on Linux, the only limit that work for that AFAIK is the size of the
address space; with zsh that is "limit addressspace 256M"; with other shells
that should be "ulimit -v 262144".

Regards,

-- 
  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/20120311/040b15da/attachment.asc>


More information about the ffmpeg-devel mailing list