[FFmpeg-devel] [RFC] the future of libamr
Diego Biurrun
diego
Sun Jun 7 22:32:05 CEST 2009
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
More information about the ffmpeg-devel
mailing list