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

[Nicolas George]

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.


> 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.

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/20120312/3340f6b0/attachment.asc>