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

[Diego Biurrun]

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

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

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
FFmpeg?

Diego

P.S.: Your exchange horribly messes up mail formatting.