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

[Michael Niedermayer]

On Wed, Jan 12, 2011 at 10:00:58AM -0500, Justin Ruggles wrote:
> On 01/11/2011 04:57 PM, Michael Niedermayer wrote:
> 
> > 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
> 
> 
> Where would shared optimized functions for data type conversion fit into
> this plan?  libavcodec needs them too.  Would those still go in
> libavcore, which would then be used by both libavcodec and libavresample?

they could be placed in avcore or avutil depending on how generic they are
if they arent audio specific we might even place them in avutil ...

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20110112/2fd7032d/attachment.pgp>