[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