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

[Michael Niedermayer]

On Mon, Mar 12, 2012 at 11:38:09PM +0100, Nicolas George wrote:
> Le tridi 23 ventôse, an CCXX, Michael Niedermayer a écrit :
> > This does not solve the problem
> > consider:
> > 
> >               --->FIFO--->SINK
> > ->FIFO->split
> >               --->FIFO--->SINK
> > 
> > if frame_immediately_available() recurses the other output will go OOM
> 
> (I hoped it would be obvious that frame_immediately_available does not
> recurse. It does not matter.)
> 
> > if it does not recurse then pushing frames into the graph will
> > cause the leftmost FIFO to go OOM as the loop removes only everything
> > from the rightmost fifos.
> 
> Yes, but the problem here is FIFO. It does not satisfy this:
> 
> > > Pushing a balanced flux unrequested frames on its inputs (what balanced
> > > means being filter-dependant) should not cause frames to accumulate anywhere
> > > before or inside the filter.

If you push a balanced mix into a box and take nothing out it will
accumulate inside
if you push in and pull out then the above filter graph does not
have an accumulation problem


> 
> 
> > anyway this doesnt look hard to fix, from a quick look a simple
> > score of how filled the to be drained fifo is could be used to
> > select fromn which sink to request()
> 
> I have thought a bit about a similar solution, some kind of "pressure" to
> decide where to pull. But my conclusion was that it was rather fragile, and
> the problem lies elsewhere, namely: filters that do not satisfy the
> statement above.
> 
> > The first problem i see with "request_frame+EAGAIN" is that
> > every request can fail at any time
> > (this is not the case ATM) and such failure needs to be handled by
> > every filter in a way that allows it to continue and retry later as
> > if the failure has never happened
> 
> As far as I know, most of the filters that are present in lavfi can already
> handle that situation pretty well. The major foreseeable problem is overlay,
> but it behaviours is already quite bogus as to when it requests.
> 
> > The second issue i see is that EAGAIN is not very finegrained,
> > for example with a source file on disk every read will succeed but
> > need time. Its preferably to read from a output that has buffered
> > data but if a output without buffered data leads to EAGAIN then
> > reading from the file would never happen
> > poll_frame() allows to empty outputs that have data and still start
> > a request when none does.
> 
> request_frame can do the job exactly the same: if data needs to be read from
> a slow medium into a cache, intiate the read and return EAGAIN immediately.

For this to work an application must run its demuxer and protocol in
a seperate thread. Not all applications do this, some are single
threaded.

With a single theraded application at the filters input a request_frame
can either call the demuxer and decoder or not call the demuxer to get
more data
With poll_frame() we can find out which output of a filter graph has
data buffered inside the filter graph. With a request_frame() that
returns EAGAIN on an empty filter graph you have a infinite loop
with one that succeeds on an empty output like on a full one you
have extra latency compared to the poll_frame() case

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20120313/edce8025/attachment.asc>