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

[Michael Niedermayer]

On Mon, Mar 12, 2012 at 10:00:49PM +0100, Nicolas George wrote:
> Le tridi 23 ventôse, an CCXX, Michael Niedermayer a écrit :
> > this can easily be solved by requireing sinks to pull. Implementation
> > wise it could be that every time theres some activity on a filter graph
> > like a frame added, we would do
> > for all sinks
> >     while poll_frame()
> >         request_frame()
> 
> That does not work: either poll_frame recurses, and that loop drains the
> first output while the other accumulate frames; or poll_frame does not
> recurse and it will never see beyond fifos.
> 
> What needs to be done is:
> 
> for all outputs
>     if !frame_immediately_available()
> 	request_frame()
> for all outputs
>     while frame_immediately_available()
> 	read_it()

This does not solve the problem
consider:

              --->FIFO--->SINK
->FIFO->split
              --->FIFO--->SINK

if frame_immediately_available() recurses the other output will go OOM
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.

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()


> 
> > fifos are necessary in some cases.
> 
> Yes, but they need to be controlled.
> 
> > that would mean such filters would need internal fifos.
> 
> Yes. But fifos they can regulate.
> 
> And I think the following statement should be true for any filter:
> 
> 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.

> 
> But all that is rather irrelevant for my point, which is: poll_frame, with
> its current semantic, is redundant to request_frame+EAGAIN.

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

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.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/72695d6d/attachment.asc>