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

[Nicolas George]

Le primidi 21 ventôse, an CCXX, Michael Niedermayer a écrit :
> assume you have 2 outputs from a filter graph
> and both will be written into seperate files
> from which do you request ?
> 
> one might output at twice the rate, if both come from the same
> source file via a split filter, half the files frames will need to be
> buffered in memory.

I grant you that the logic implemented in my patch can not accommodate
filter graphs with multiple output. But neither did the current version
anyway, and poll_frame, as it is currently done, can not help with that. I
can elaborate on that if someone is interested but it would be a bit long.

Supporting graphs with multiple outputs is hard with the mixed
input-/output-driven model. But I am convinced that any solution can be made
to work with request_frame directly.

> Or another example
> you have a demuxer + decoderS and the lets say 2 streams get then
> inserted into a filter graph and that has 2 outputs.
> From which output do you read
> There may be half a second of audio available ready to be used while
> reading video might requre the demuxer and the connected protocol (UDP
> V4L whatever) to wait for more data.
> poll_frame() reduces latency here. Which would matter if it was
> realtime communication or the memory was very constrained.

This is the classic problem with blocking devices or protocols. A clean
solution would require a poll feature capable of monitoring several links at
once, just like the Unix poll() function does. The current implementation
does not allow that at all. The second best solution are non-blocking plus
active polling, possibly coupled with threads; we can do that with
request_frame.

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/a8ca60bf/attachment.asc>