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

[Michael Niedermayer]

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

yes that was my plan, have audio resample/format change code like swscale

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/ec357506/attachment.pgp>