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

Baptiste Coudurier baptiste.coudurier
Tue Jun 9 00:43:34 CEST 2009

On 6/8/2009 2:17 PM, Diego Biurrun wrote:
> On Mon, Jun 08, 2009 at 02:08:17PM -0700, Baptiste Coudurier wrote:
>> On 6/8/2009 1:51 PM, Diego Biurrun wrote:
>>> On Sun, Jun 07, 2009 at 01:38:26PM -0700, Baptiste Coudurier wrote:
>>>> 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:
>>>>>>>> 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.
>>> I'm saying that implementations and reimplementations have been funded
>>> by outside sources.  If the coder being funded was a part of the FFmpeg
>>> team or not is irrelevant.
>> Libswscale and Animated gif were funded ?
> I did never claim that.
>> Hell, no, that's exactly the point. Nobody will "reimplement" something
>> that works because of FFmpeg's own interest, except one FFmpeg
>> developper or one developper from GSOC which was paid thanks to FFmpeg.
>> Now one company gratefully funded HE-AAC after the project was started
>> and left over from GSOC, that's great and I wish there would be more,
>> however it's not done yet, I hope it will be soon, but I don't think
>> removing libfaad did all help on this, it's still there in the tree and
>> hopefully it is otherwise you couldn't decode HE-AAC.
> You are confused.  libfaad was never removed.  Robert asked to keep it.
> HE-AAC was not a leftover from GSoC, regular AAC decoding was.  HE-AAC
> is being sponsored despite the fact that libfaad decodes it perfectly.
> Robert was also funded to get the SoC regular AAC decoder into FFmpeg.

I don't think I'm not confused. However you seem to be missing my point.
Yes it wasn't removed and because it was _not_, it tends to show that
it's not necessary nor helping to _remove_ it. That's an argument in
favor of _not_ removing libamr wrapper for WB encoding.

>>>>>>> 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.
>>> Correct.  It costs both myself as representative of FFmpeg credibility
>>> as well as FFmpeg as a project.
>> I think many developers could be and IMHO should be representative of
>> FFmpeg credibility. In case you didn't get it, I'll make it clear this
>> time: replace "myself" by "us". Thanks for your understanding.
> You seem to misunderstand what I am talking about.  When I deal with
> license violators, the credibility of other individual devs is not on
> the line.  It's just me personally and the project as a whole.

I completely understand what you are talking about, and IMHO issues
should be dealt in the name of FFmpeg, the project, if you wish you
include yourself and I wish to be included as well, I think you should
use "us".

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

More information about the ffmpeg-devel mailing list