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

Robert Swain robert.swain
Sun Jun 7 22:39:13 CEST 2009


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:

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

One could say:

Nobody is happy to see non-free code in use in free software, but the 
current situation represents a tradeoff with a negative balance. We drop 
some non-free code, but we also lose a feature and there's no guarantee 
when we might get a replacement.

>>>>> Also it might be useful in the future for people actually implementing
>>>>> amb-wb encoding, the same way we still have libfaad wrapper.

+1

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

I would also prefer to keep AMR-WB encoding, but as I was the only one 
making noise earlier I was willing to let it slide. I'll lend my vote to 
the "let's keep AMR-WB encoding support" camp.

Regards,
Rob



More information about the ffmpeg-devel mailing list