[FFmpeg-devel] [RFC] the future of libamr
Pavel Pavlov
pavel
Sat Jun 6 15:59:07 CEST 2009
> -----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
More information about the ffmpeg-devel
mailing list