[Ffmpeg-devel] ac3enc.c modifications

[Michael Niedermayer]

Hi

On Sunday 15 May 2005 08:33, Rich Felker wrote:
> On Sun, May 15, 2005 at 07:36:53AM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Sunday 15 May 2005 03:10, Justin Ruggles wrote:
> > [...]
> >
> > > Some comments while I'm all psyched:
> > >
> > > DC filtering:  I agree with Michael that filtering should be left out.
> > > libavcodec is a library, not an application, so filtering the input
> > > would be presumptuous.  FFmpeg, however, is an application, but audio
> > > filtering might just be overkill...i dunno...
> >
> > its ok in its own c file and used by ffmpeg.c, though eventually
> > libavfilter would be nice ...
>
> hmmm.. :)
> i'd be interested in writing it. actually i scrapped my plans for
> mplayer g2/g3 in hopes of building a good player on top of just
> lavc/lavf instead since they're quickly on the way to having good api
> and supporting all formats that have been reverse engineered.

great :)


>
> 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

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 ...


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

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

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

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

[...]
-- 
Michael