[FFmpeg-devel] [GSoC] Qualification Task
stefano.sabatini-lala at poste.it
Thu Mar 24 18:33:11 CET 2011
On date Thursday 2011-03-24 10:35:53 +0200, Mina Nagy Zaki encoded:
> 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:
> > 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?
In other words suppose that a filter receives a request_frame() (for
example, aout pulling filtered samples).
If you don't need to buffer samples for filtering, you can simply
handle the incoming samples in filter_samples() and send them
immediately to the output filter(s).
If you need to buffer samples, then you'll implement a request_frame()
callback, which will buffer samples by calling avfilter_request_frame
until you filled your buffer and can proceed with the actual
> I haven't actually found a filter that employs both draw_slice/filter_samples
> and request_frame callbacks in such a manner.
IIRC fifo works this way.
> > 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.
Uhm, what do you exctly mean with "actually breaks the draw_slice function stack"?
> 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.
Anyway I suppose you can also implement a pure pull model. You simply
call filter_samples on the source, which will create the samples and
send them to the next filter, up to the last filter in the
filterchain. But note that in ffplay/ffmpeg you actually need to pull
frames from the sink, because this is how the applications work (that
is, they call avfilter_frame when they need data to inject to the
output file / to SDL).
What's exactly the problem that you're addressing?
> [snip: patch comments]
> I've applied all requested changes, added copyright notice, check
> for 44.1kHz and docs.
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 32f68f7..3b6bf4e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
Looks fine, I'll push it to the public branch I'm going to setup for
audio filters, nice job! :)
PS For posting patches the recommended way is attaching the patches
git format-patch REV.
FFmpeg = Forgiving and Funny Minimalistic Puristic Earthshaking Guru
More information about the ffmpeg-devel