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

[Diego Biurrun]

On Sun, Jun 07, 2009 at 01:22:20PM -0700, Baptiste Coudurier wrote:
> Diego Biurrun wrote:
> > 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.
> 
> While I can see how this can be true, in practice I believe this has
> proven to not have many results outside of FFmpeg.
> Libswscale was reimplemented by Kostya, AAC decoder by GSOC then Robert,
> now Alex, but this was still driven by FFmpeg and animated which I
> reimplemented myself.

I disagree.  HE-AAC is being sponsored by a Finnish company, you did
quite a bit a bit of implementation work for your company, there are
more examples..

> > 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.
> 
> "me" ? You mean FFmpeg

I mean both FFmpeg as a project as well as myself when dealing with
license violators.

> > 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.
> 
> However we are asking people to code and submit patches against latest svn.

Sure, but this is not about submitting patches.

> >>>> 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?
> 
> I'm sorry but no. I'd like to keep libamr AMR-WB encoding feature until
> someone start implementing one within FFmpeg.

Then we must vote.

Diego