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

Jai Menon jmenon86
Mon Jun 8 06:30:04 CEST 2009

On Mon, Jun 8, 2009 at 2:02 AM, Diego Biurrun<diego at biurrun.de> 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..
>> > 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.

I don't know whose opinions are being solicited here, but imho we
should keep it around till somebody with serious interest in a native
implementation shows up (or amr-wb encoding is added to opencore etc).



More information about the ffmpeg-devel mailing list