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

[Baptiste Coudurier]

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.

> 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

> 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.

> 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.

I don't think so.

>>>> 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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org