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

[Michael Niedermayer]

On Tue, Jan 11, 2011 at 09:09:49PM +0100, Stefano Sabatini wrote:
> 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).

What we need is this darn resample code in libavfilter because some filters
need it. Until it is moved there or in a dependancy of libavfilter,
work cannot continue in the related filters. <- This is a problem and VERY bad

It does not belong in libavcore unless there is a need for this code from a
second library
libavresample is a great idea but we do NOT have a qualified volunteer to
write this besides its a long term plan. moving code != writing libavresample

grand audio plan
phase 1: unblock the libavfilter audio work, copy code in there, deprecate in
         libavcodec, eventualy remove from libavcodec (i said this months ago)
phase 2: design libavresample API
phase 3: implement libavresample API
phase 4: update filters to use libavresample

your way A:
phase 1: move code to avcore
end with insufficent API made public


your way B:
phase 1: move code to avcore
phase 2: design libavresample API
phase 3: implement libavresample API
phase 4: update filters to use libavresample
phase 5: be stuck with cruft in libavcore or a dependancy on libavresample

your way C:
phase 1: design libavresample API
phase 2: implement libavresample API
phase 3: update filters to use libavresample
Block libavfilter work for a year



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

I dont know what you talk about but iam currently working on fixing avfilter
vf_pad and would prefer to contiue to fix whatever else is buggy there instead
of arguing about this

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/20110111/717eba19/attachment.pgp>