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

[Pavel Pavlov]

> -----Original Message-----
> > OK, then I guess the only issue is a feature regression in that 
> > libopencore-amrwb doesn't do encoding. As Diego points out, there's 
> > nothing stopping people from using FFmpeg 0.5 or a version 
> of svn from 
> > before the libamr reference wrapper gets removed, but I'm 
> not really 
> > fond of feature regressions. Is there any good reason not 
> to keep the 
> > libamr-wb reference encoder wrapper?
> 
> May I suggest that you read the 25+ messages in this thread 
> before restarting the discussion at square one?  Pros and 
> cons have already been hashed out extensively and a consensus 
> seemed to have been reached.
> If you have anything new to add, reply to the relevant 
> subthread.  Just raising the same concerns over and over 
> again is inconstructive and leads nowhere.
> 
> Diego

I have a question, is the plan to drop libamr and to use opencore-amr,
or to write own ffamr?
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. 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.
Then I tried to compare x86 build of our code to optimized floating
point 
encoder for x86 from voiceage and their encoder was like twice faster 
(whereas their optimized encoder for arm was slower around 30-40% than
ours)
In our version I didn't do any aggressive x86 optimizations, as we
needed
it to run on a specific arm cpu, so it could be the reason why I got 
fixed point slower.
And more at the end, somewhere I read that floating point implementation

produces better quality bitstream, but in practice in my headphones I
didn't 
notice any difference of course. So, even libamr doesn't offer
highperformance
encoding, it's still is usable on modern hardware and will encode/decode
bit exact stream