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

[Michael Niedermayer]

On Tue, Mar 13, 2012 at 07:26:56PM +0100, Nicolas George wrote:
> 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.

This sounds much better indeed


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

many

1. one could show the video a few frames ago in a smaller picture in
the big one as an effect like if someone pointed a camera onto a
monitor displaying the video from the camera

2. one could with several simple filters construct a denoise or
temporal average (IIR) filter, with audio it could be a echo filter.

3. if one made a movie one could for example refer in the movie to a
recording of some earlier part of the movie by having that displayed
via a picture in picture filter or as a flashback (this maybe isnt
the most sane way to implement that though)

4. iam sure there are various effects one could do with it ...


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- 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/afc2afb6/attachment.asc>