[FFmpeg-devel] [PATCH] Move audioconvert API from libavcodec to libavcore.
Stefano Sabatini
stefano.sabatini-lala
Tue Jan 11 23:29:51 CET 2011
On date Tuesday 2011-01-11 22:57:26 +0100, Michael Niedermayer encoded:
> 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:
[...]
> > > > > 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
Makes sense. If you plan to have a distinct libavresample (as opposed
to having resampling code in libavcore, as I was assuming) this is the
best design. Thus I drop the patch.
[...]
--
FFmpeg = Fanciful & Faithful Magnificient Puristic Elastic Gigant
More information about the ffmpeg-devel
mailing list