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

[Nicolas George]

Le quartidi 24 ventôse, an CCXX, Michael Niedermayer a écrit :
> My point is that you have not stated clearly what you propose but the
> way i understand your suggestion would render the filter framework
> useless or at least severly crippled in terms of what a user can do.
> 
> 1. your axiom requires zero accumulation inside filters
>    Many practical filter frameworks a end user will want to use
>    need accumulation inside the graph.
>    examples would be filters working with synchronizing 2 or more
>    streams, some hardsub filter, ... Theres need to delay/accumulate
>    on at least one stream to sync.
This part is a misunderstanding. The axiom I would like to see enforced
requires zero accumulation _if the inputs are balanced_.

I take your example of a filter that synchronizes two streams: if its inputs
are already synchronized, it does not need to accumulate anything. That is
what I call balanced.

If the inputs are not synchronized, it must accumulate, of course, and I do
not want to change that.

Maybe I can be more clear by stating it the other way: a filter should
output its frame as soon at it can, as a reaction from one of its input, and
not wait for a request on its output.

>    Also there are good reasons why a filter graph itself should be
>    a filter that can be part of another filter graph. But if you
>    allow accumulate at the end of a graph and not inside a filter graph
>    then its not possible for a generic filter graph to be a filter

There is a difference between a filter and a filter graph: when the filter
has had enough input, it can actively output. With a filter graph, assuming
the outputs are made of buffersinks, all it can is accumulate the frames in
the sink, waiting for the surrounding code to read them.

In other words, if the axiom I propose is true for the filters, it becomes
true for the whole graph, seen as a filter by itself, provided the output of
the graph is handled by something smarter than buffersink.

Again in other words: what I want is to forbid push-only-if-requested
filters, especially fifo, in the middle of the graph. And buffersink is a
push-only-if-requested connection between the graph and the rest of the
code.

> 2. If a push always causes a push on the output then

Not always: only if there is enough input. For example, a filter that
pastes two video frames, one of the left and one of the right (disregarding
any PTS; that is a stupid filter, just for the sake of argument) will push
only when it has one frame on each input. But it should push as soon as it
has.

>    filters with multiple inputs would increase pushes and
>    feedback loops in the graph would infinitly increase pushes leading
>    to infinite lopps
>    Allowing loops and feedback was a design goal and is supposed to
>    be supported currently.

I do not understand the kind of feedback loop that would make sense in a
filter graph. Do you have a practical example?

> I see 2 problems with droping poll_frame()
> 1. filters with multiple inputs need to support a failing
>    request_frame() at any point, store state and be able to resume.

They have to do that exactly the same if poll_frame returns false.

> 2. with buffering in the middle of filter graphs the EAGAIN system
>    seems to have issues

True. And that is why I want to eliminate uncontrolled buffering in the
middle of the graph.

>			  (current poll_frame too has them but it seems
>    easier to fix with poll_frame)

I am convinced it is easier to fix with EAGAIN: single code path.

> Either way, if you can simplify libavfilter while allowing arbitrary
> filter graphs to be filters, allowing feedback loops, allowing delays
> for syncing streams, and allowing avfilter to be efficiently used in
> a wide varity of applications (they may be more push or pull oriented
> and may be single theaded)
> then iam certainly in favor of such simplifications but i dont want to
> loose signifciant features ...

I would really like to see a concrete example of feedback loop that need to
be possible. Of course, a reference to a past discussion would do.

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/20120313/132e033b/attachment.asc>