[Ffmpeg-devel] ac3enc.c modifications

Rich Felker dalias
Sun May 15 19:52:47 CEST 2005


On Sun, May 15, 2005 at 06:33:29PM +0200, Michael Niedermayer wrote:
> > do you have any ideas in mind for the sort of api you'd want it to
> > use? my main requirements are advanced buffer management for optimal
> > processing without extra memcpy, proper pts handling, and (but this is
> > open to discussion) pull-driven from the end of the filter chains.
> 
> well, one thing i want is that it should be possible to write correct filters 
> without having to understand every detail of the filter system, unless of 
> course the filter system is so trivial that it wouldnt be a problem to learn 
> it all quickly

my idea was to have several different profiles of filters...

the simplest would be 'local' filters which no nothing about 'frames'
or surrounding context. the filter layer would manage the buffers
entirely, and just call one function with the input and output buffer
addresses (possibly the same if the filter flags that it allows that)
and a width/height/stride (or length for audio) to process.

next would be semilocal filters, which don't need to know anything
about buffer management but do need some context. a system like your
block handling in libpostproc would ensure they always have sufficient
context before calling the actual filtering function. things like
resamplers, audio equalizers, deblockers, deinterlacers go here.

on the other end of the spectrum, there would be support for filters
which fully interact with the buffer management, for things that need
it (long term temporal processing, duplicate frame removal, inverse
telecine, motion adapting deinterlacing, ...)

some profile in between? i dunno, haven't thought of what it would
be...

> i would also prefer if filters dont call either directly or indirectly any 
> functions from other filters, though i would change my mind about this if 
> that would mean some disadvantage or increase in complexity ...

agree totally.

> another thing is that IMHO the buffer handling/managemant code should be kept 
> outside of the filters, not only would it simplify filters but it would also 
> greatly simplify the case where we need to change the buffer handling

agree strongly.

> one simple possibility would be a system where each filter provides
> 
> get_inlen_for_outlen(int in_length[], int out_length);
> 
> int filter(void *out, void **in, int in_length[], int consumed[])
> in would be the input streams, in_length[] their available lengths and 
> consumed would be used to return how much of the input has been used and wont 
> be needed ever again, on the next call in would contain all the not yet 
> consumed samples and at least as much as get_inlen_for_outlen() says

this is similar to what i had in mind for the fully-general (nonlocal)
audio filter api, except that i was going to use a dynamically
shrinking/growing buffer struct with read/write positions which the
source and dest filters would update directly.

> in place filtering could also be done trivialy with that by simply setting the 
> out array equal to one of the in arrays if the filter supports it

in-place is useful for video, imo not so useful for audio, but it
could still be done for sure with local filters if the core wanted to
deal with the complexity.

> these filters should be useable with both in push and pull filter cores

yes. your idea of multiple filter cores is interesting. what if
libavfilter specifies one sufficiently general api for filters to
implement, then also provides multiple 'filter cores' which the
application can use (or provide its own filter core instead) to call
them in various ways, depending on its needs?

rich





More information about the ffmpeg-devel mailing list