[Ffmpeg-devel] ac3enc.c modifications
Sun May 15 18:33:29 CEST 2005
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.
> 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
More information about the ffmpeg-devel