[FFmpeg-devel] [PATCH] audio fifo filter for lavfi

[Michael Niedermayer]

On Thu, Sep 23, 2010 at 08:41:40AM -0700, S.N. Hemanth Meenakshisundaram wrote:
>  On 09/22/2010 07:32 PM, Michael Niedermayer wrote:
> > On Wed, Sep 22, 2010 at 07:05:16PM -0700, S.N. Hemanth Meenakshisundaram wrote:
> > [...]
> >> +
> >> +static int request_frame(AVFilterLink *link)
> >> +{
> >> +    FifoContext *fifo = link->src->priv;
> >> +    BufSamples *tmp;
> >> +    int err;
> >> +
> >> +    if (!fifo->root.next)
> >> +        if ((err = avfilter_request_frame(link->src->inputs[0])) < 0) {
> >> +            fifo->frame_requests_pending++;
> >> +            return err;
> >> +        }
> > elaborate please on how this can work
> > frames have no known size, anything calling request_frame() 5 times could
> > as a result get 5 samples or 5 billion samples
> > simply setting frame_requests_pending=1 would likely do the same
> > but this seems not what you intended it to do
> >
> >
> 
> Isn't that what we want here? The number of samples in the frame would
> depend on how the decoder produces frames or on how any preceding filter
> in the chain puts new frames together. The fifo would simply queue these
> frames (whatever their size) and then send them to the next filter.
> If the next filter called request frame n times without getting any
> data, then the fifo filter would skip queueing and directly pass frames
> the next n times.
> 
> I guess poll frame too should then report the number of frames instead
> of samples.

frame count is meaningless if the size of frames can be anything and can
change arbitrarily.


> 
> Though the size of a 'frame' is undefined, it should be a reasonable
> number of samples unless the decoder or any other filters are written to
> produce frames of too few/too many samples.

and if its not reasonable things break down or they where not needed in the
first place, this doesnt seem good to me


> 
> One alternative would be to allow a filter to specify the number of
> samples it expects during initial configuration (including an option to
> just accept whatever the preceding filter gives). If a filter will only
> accept a specific number of samples per frame, we can have an
> auto-inserted filter manage unpacking, buffering and repacking samples
> into frames as required. Would this be a better idea?

there are filters that work on a sample by sample basis
out[i]=f(in[i])

and there are filters that work on a context base like
out[i]= f(in[i-5], ..., in[i+5])
these do not work with frames as they are but require aditional buffering
or use of multiple frames (and if frames are too small that might even be
>2)
FIR and resample filters fall in this category

neither of them cares about the frame size but the CPU cache cares and
call overhead affects it too, too big is bad too small is bad too

and as 3rd category there are windowed FFT based filters, they work on
fixed size but they require context for the windowing too aka they need
frame 0+1 then 1+2 then 2+3 for example (and these frames must have the
exact size of the FFT


so far we had 1 in 1 out filters
with merge filters the question arrises if the core or the filter takes
care of ensuring the input is synchronized
for example input 1 might receive frames of size 700 while input 2 gets
frames of size 701. if the core doesnt compensate then each merge filter
will need to deal with that

i do not know how all this can be handled best ...

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100924/cbd983f2/attachment.pgp>