[FFmpeg-devel] [GSoC] Qualification Task

Mina Nagy Zaki mnzaki at gmail.com
Thu Mar 24 09:35:53 CET 2011


On Wednesday 23 March 2011 19:03:28 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:
> > [...]
> > 
> > > > In both cases I can't seem to figure out how I can find the end of
> > > > stream, which is important for some effects as they need to 'drain'
> > > > (like the echo effect).
> > > 
> > > I suppose you read AVERROR_EOF from avfilter_request_frame() when you
> > > reach the end of a stream. Note that I'm a bit rusty with libavfilter
> > > audio, as it is some months I don't touch that code and I don't have a
> > > good memory ;-), but I remember there was a problem with some filters
> > > which needed that (in particular a video concatenation filter).
> > 
> > [...]
> > 
> > > 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. I have examined most of the RFC thread
> > about lavfi audio, but I couldn't really find a discussion about
> > push/pull models. The current mixture is a slight mess.
> 
> Check avfilter_request_frame(), it calls the request_frame callback if
> defined on the source pad, otherwise calls avfilter_request_frame() on
> the first input link of the source filter.
> 
> In other words we have a mixed pull/push model, you pull frames, and
> as a consequence the filterchain pushes frames on the
> filterchain. There is nothing wrong in implementing a frame_request
> callback in the output pads.

Ok, I'm still a bit confused. So first request_frame is called on my output 
pad, at which point I need to pass on the request, and the chain of events 
eventually leads to filter_samples being called on my input pad _OR_ I get EOF 
on my request_frame. So essentially that means I do filtering in filter_samples 
and draining in request_frames (where I know it's EOF), and when I'm done with 
draining I need to actually send down the samples through 
avfilter_filter_samples to the rest of the chain, right?

I haven't actually found a filter that employs both draw_slice/filter_samples 
and request_frame callbacks in such a manner. 

> This is essentially what is done in the case of video, check for
> example how it is done in fifo (and of course you need to implement it
> in a source). I don't know if this is a mess, but don't worry, we'll
> fix it ;-).

Yes, vf_fifo does pass on frames through avfilter_draw_slice from inside its 
request_frame callback, and actually breaks the draw_slice function stack
using an empty callback. 
But then what's wrong with a pure pull model at least for audio (because 
video, it seems, requires the start_frame/end_frame calls)? That is, I get 
data on request_frame and I process it and return? I could actually do that 
and use a null filter_frames callback to simply break the function stack.

[snip: patch comments]
I've applied all requested changes, added copyright notice, check
for 44.1kHz and docs.

-- 
Mina
-------------- next part --------------
A non-text attachment was scrubbed...
Name: earwax_filter.patch
Type: text/x-patch
Size: 8190 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110324/2b8561a4/attachment.bin>


More information about the ffmpeg-devel mailing list