[FFmpeg-devel] [RFC] Flush API for libavfilter

[Michael Niedermayer]

On Thu, Oct 20, 2011 at 05:06:21PM +0200, Stefano Sabatini wrote:
> On date Wednesday 2011-03-23 06:25:15 +0200, Mina Nagy Zaki encoded:
> > On Tuesday 22 March 2011 17:35:39 Stefano Sabatini wrote:
> [...]
> > > Check: cmdutils.c:get_filtered_audio_buffer(), it implements a pull
> > > model, correct me if I'm wrong.
> > 
> > I have already checked that, which is what lead me to the question in the first 
> > place. I can't really read AVERROR_EOF from request_frame() because audio 
> > filters don't(/shouldn't?) use it. get_filtered_audio_buffer() does a 
> > request_frame() on aout which propagates all the way to asrc (without passing 
> > through intermediate filters, because they don't/shouldn't use it) which then 
> > does a filter_samples that propagates all the way to aout! If I try to 
> > request_frame from the previous buffer it will reach asrc then eventually lead 
> > to calling my own effect's filter_samples, so now do I filter in filter_samples or 
> > request_frame :D  And in any case, asrc never returns AVERROR_EOF anyway.
> 
> Hi,
> 
> I was trying to get the af_sox.c filter in shape when I stumbled
> across this.
> 
> Resuming, the problem is that when a filterchain source returns
> AVERROR_EOF (e.g. becase the generated media has terminated) it is not
> possible to notify the intermediate filters, which may keep cached
> data which is never released.
> 
> For example some sox filters cache data, which is supposed to be
> flushed through the drain API when *all* the input has been already
> provided (so they won't return data *at all* if such a mechanism is
> not implemented).
> 
> This can't be done with the current API (neither with audio nor with
> video).

I dont understand the problem for video

At EOF
A filter currently can, when it receives a request_frame()
push the next cached frame out via
avfilter_start_frame + avfilter_draw_slice + avfilter_end_frame
vf_yadif does this currently for different reasons

And a filter knows its at EOF when poll & request_frame() signal so
that is via 0 and AVERROR_EOF

The pull system is needed or more complex networks of filters will
have all kinds of issues.
one example is a graph with 2 inputs and 2 outputs, we assume
one wants to mux these 2 outputs together in the same file, the inputs
are from seperate files. With a pull system we know from which file
to read next with a push system we dont and could end up having to
buffer the whole decoded file in memory. Not to mention the delay
So i think audio should use request_frame() or a equivalent too

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- 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/20111020/170d6891/attachment.asc>