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

[Baptiste Coudurier]

Diego Biurrun wrote:
> 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..

You disagree with what exactly ? That reimplementation was done inside
FFmpeg team ? I'm sorry but I really believe this is true. Most (maybe
all) reimplementations were done by someone from FFmpeg team, or from
GSOC which was explicitely wanted and driven by FFmpeg team.

Also "implementation" != "reimplementation", I did not reimplement much
except GIF decoder, which is only for the sake for FFmpeg here, I don't
have interest in animated gif 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.
>> "me" ? You mean FFmpeg
> 
> I mean both FFmpeg as a project as well as myself when dealing with
> license violators.

It would more adequate to say "us" here then I think.

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

Implementing AMR-WB encoding will certainly be 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.
> 

I'm fine with that.

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