[FFmpeg-devel] [RFC] the future of libamr
Sat Jun 6 17:54:49 CEST 2009
On Sat, Jun 06, 2009 at 09:59:07AM -0400, Pavel Pavlov wrote:
> I have a question, is the plan to drop libamr and to use opencore-amr,
> or to write own ffamr?
I have just added OpenCORE support. I plan to drop libamr support after
the weekend. There is an ongoing Google Summer of Code project to
finish the AMR-NB decoder and write an AMR-NB encoder. Work on the
G.729 decoder was just resumed and might eventually lead to an AMR-WB
I expect the AMR-NB decoder to get finished this year. For the rest,
nobody knows but I guess we will eventually get there.
> All the concerns about copyrighted code in libamr do not go away with
> libopencore as it uses copyrighted ref implementation with some minor
> modifications. Seems like android got permission to redistribute it
> as part of their project, IMO it doesn't mean that anybody can freely
> use opencore now.
OpenCORE is released under the Apache 2.0 license and is thus free
software. I have seen no reason to question the validity of the
If you have such reasons, you need to provide us with facts.
> Libamr uses floating point, opencore is fixed point and
> they aren't binary compatible, ie fixed point doesn't pass regression
> tests for floating point and vise versa.
> One more thing, seems like floating point version will run faster on
> i386, whereas on arm it probably won't even run realtime. The reason
> I think so is because I made some tests. We used some comercial
> optimized implementation of amrnb for arm cpu, but at some point for
> a project we needed to have multiple realtime voice streams
> encoded/decoded with amr; So, we decided to try other comercial
> implementations and in parallel we tried to do our own implementation.
> It appeared that at the end our implementation was around 30% faster
> than others (and code size smaller, compared to voiceage arm-optimized
> lib ours is 5 times smaller) and was still able to pass reference
> validation vectors; with some non bitexact math it was even faster
> but didn't pass vectors in such case off course.
So why don't you release your implementation and get it merged into
P.S.: Your exchange horribly messes up mail formatting.
More information about the ffmpeg-devel