[FFmpeg-devel] [PATCH] Move audioconvert API from libavcodec to libavcore.

[Stefano Sabatini]

On date Tuesday 2011-01-11 20:23:40 +0100, Michael Niedermayer encoded:
> On Tue, Jan 11, 2011 at 06:25:07PM +0100, Stefano Sabatini wrote:
> > On date Tuesday 2011-01-11 15:23:45 +0100, Michael Niedermayer encoded:
> > > On Tue, Jan 11, 2011 at 01:10:41PM +0100, Stefano Sabatini wrote:
> > > > On date Tuesday 2011-01-11 01:52:46 +0100, Michael Niedermayer encoded:
> > > > > On Tue, Jan 11, 2011 at 01:35:45AM +0100, Stefano Sabatini wrote:
> > > > > > On date Tuesday 2011-01-11 00:55:46 +0100, Michael Niedermayer encoded:
> > > > > > > On Tue, Jan 11, 2011 at 12:20:39AM +0100, Stefano Sabatini wrote:
> > > > > > > > On date Sunday 2011-01-09 19:52:26 +0100, Michael Niedermayer encoded:
> > > > > > > [...]
> > > > > > > > +int av_audio_convert2(AVAudioConvertContext *ctx,
> > > > > > > > +                           void * const out[8], const int out_stride[8],
> > > > > > > > +                     const void * const  in[8], const int  in_stride[8], int len)
> > > > > > > > +{
> > > > > > > > +    int ch;
> > > > > > > > +
> > > > > > > > +    //FIXME optimize common cases
> > > > > > > > +
> > > > > > > > +    for (ch = 0; ch < ctx->out_channels; ch++) {
> > > > > > > > +        const int is =  in_stride[ch];
> > > > > > > > +        const int os = out_stride[ch];
> > > > > > > > +        const uint8_t *pi=  in[ch];
> > > > > > > > +        uint8_t *po  = out[ch];
> > > > > > > > +        uint8_t *end = po + os*len;
> > > > > > > > +        if (!out[ch])
> > > > > > > > +            continue;
> > > > > > > 
> > > > > > > does git blame pick up this reformated code and associate it correctly to the
> > > > > > > original commits ?
> > > > > > 
> > > > > > No, I'll revert the formatting.
> > > > > 
> > > > > Thanks alot
> > > > 
> > > > I'll apply this night if there are no other comments.
> > > 
> > > Why is this code moved into libavcore and not libavfilter ?
> > 
> > ???
> > 
> > Do you want to make libavcodec depend on libavfilter?
> 
> id like to avoid having code moved around guided on dependancies that are
> going to be removed.
> 
> The only reason why audio resampling or similar would be needed in avcodec is
> if a decoder or encoder needed it for functioning or optimization.
> Thats not impossible but iam not aware of such a case currently.
> 
> We have had and exportet the audio resample stuff from avcodec historically
> because that happened to have been the best place for it.
> I really would like to drop the whole filtering API from libavcodec 
> and require users to use libavfilter or a libavaudio like libswscale.
> 
> 
> > Also audio
> > resampling is not necessarily related to filtering, you may need to
> > resample without the need for libavfilter, libavcore seems the right
> > place to me.
> 
> any single filter can be needed without the others
> also one surely can want resampling without anything else of teh core

All the libav* libraries (but libavutil) already depend on libavcore,
and one of the main reasons for having libavcore was "to share common
multimedia utilities amongst the libav* libraries", audio resampling
utilities seem to perfectly fit in this description.

The other idea I proposed was to have a libavresample lib, with a role
similar to that of libswscale, but then when we moved samplefmt stuff
to libavcore I supposed the libavcore way was preferred (not that we
can't revert this decision).
 
> API design always must be weighting alternatives, it never can be based on a
> single argument or use case that would favor one design over the other.
> Reason being that you can construct an argument for absolutely anything
> 
> With above argument you end up with a single filter per lib, and tomorrow with
> a single codec per lib, and the day after with several libs per single codec one
> for interlaced material one for progressivem, ... because there always can be
> someone who needs just a subset ...

Having a modular architecture is not a specific requirement but a
design principle. For the way I see libavfilter, it's a kind of high
level library, which shouldn't be needed for low level processing as
audio resampling and decoding, that's why I insist for keeping
libavfilter and libavcodec decoupled.

Note also that you force libavfilter-related ffmpeg regressions (which
can now be avoided with --disable-avfilter) the same moment you make
libavcodec depend on libavfilter.
-- 
FFmpeg = Fierce & Furious Mere Proud Extroverse God