[FFmpeg-devel] [RFC] the future of libamr

Diego Biurrun diego
Sun Jun 7 22:10:51 CEST 2009

On Sun, Jun 07, 2009 at 12:45:15PM -0700, Baptiste Coudurier wrote:
> Diego Biurrun wrote:
> > On Sun, Jun 07, 2009 at 12:10:57PM -0700, Baptiste Coudurier wrote:
> >> Diego Biurrun wrote:
> >>> Have you read through the discussion in the meantime?  Do you think the
> >>> tradeoff between the benefits and drawbacks of removing libamr support
> >>> is bad?  Why?
> >> I'm not for feature regressions.
> > 
> > At all costs?
> Certainly not. IMHO, for libamr case, it's already there and keeping it
> does not cost anything.

It costs us the opportunity that somebody might get motivated to
implement AMR-WB encoding support.

It also costs me some credibility when dealing with license violators.
We do not like companies distributing nonfree builds of FFmpeg, but we
keep the means to create such builds.

AMR-WB encoding is a very obscure feature.  We hardly have a sample or
two.  You can always transcode to WAV and feed that to an old binary
with libamr support.

Nobody is happy to see features go, but the current situation represents
a tradeoff with a positive balance.  We lose an obscure feature, but we
can drop some nonfree code and we have a higher chance of getting a free
native replacement.

> >> Also it might be useful in the future for people actually implementing
> >> amb-wb encoding, the same way we still have libfaad wrapper.
> > 
> > For these use cases the 0.5 branch will remain available.  Also Colin,
> > the person currently working on AMR-NB decoding and encoding has clearly
> > stated that he does not make use of libamr.
> We are talking about AMR-WB case here, being able to use AMR-WB and
> latest for the sake of reporting bug reports is far more convenient.

Fine.  If somebody credible turns up to work on AMR-WB encoding support
and libamr support in HEAD would help, I promise to restore libamr.c.
Is that good for you?


More information about the ffmpeg-devel mailing list