[opus] OPUS on embedded platforms

[Mike Hooper]

JM,

I agree that one should only need a portion of the codec. It's just figuring
out WHICH portion to include that is difficult....:) For those of us who
aren't as familiar with the guts of the code (which is rather complex), that
process is a huge investment in time. Also, I believe the RAM (stack)
requirements have gone up considerably since CELT v.8. It seems that the
codec structures are much larger and more complex than before, which for the
C55xx with only ~256kbytes for both code and stack, is a non-starter.

Optimizing the CELT code for both limited MIPS and limited RAM is far beyond
my expertise and I am sure, most others. I would love to see one of you guys
take this on (in your spare time...:)

Thanks again for this wonderful technology!



-----Original Message-----
From: Jean-Marc Valin [mailto:jmvalin at jmvalin.ca] 
Sent: Tuesday, December 18, 2012 1:54 PM
To: Mike Hooper
Cc: 'Timothy B. Terriberry'; opus at xiph.org
Subject: Re: [opus] OPUS on embedded platforms

Hi Mike,

Well, the first thing is you don't have to include all of the encoder if
all you're only planning on encoding with the CELT mode (you should
still have the SILK decoder for compatibility, but it's much smaller).
There's also what we call OpusCustom, which is equivalent to the
original CELT code, but that has interoperability issues (same as the
old CELT code).

Generally, I would expect low-power embedded applications to only ship a
subset of the encoder, but not necessarily the same for everyone. For
example, I could imagine a cheap SIP phone to only ship the narrowband
SILK encoder, possibly even removing the higher-complexity encoding modes.

Cheers,

	Jean-Marc

On 12-12-18 12:41 PM, Mike Hooper wrote:
> Timothy, Jean-Marc, et al,
> 
> I would very much like to see an "embedded" version of Opus developed that
> is optimized for small size and much higher performance (at least on the
> CELT side of the codec). I am using V.8 of CELT which takes about 60MIPS
> (encode) and 40MIPS (decode) of a TI C5515 100MHz DSP. I have tried to
> squeeze Opus into a C55xx but the size of the code has grown to the point
> where it requires external memory. Since the C55xx does not have cache,
the
> performance is not usable. 
> 
> I would imagine that there is a large potential user base of an
> embedded-specific code base.
> 
> -----Original Message-----
> From: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of
> Timothy B. Terriberry
> Sent: Tuesday, December 18, 2012 11:21 AM
> To: opus at xiph.org
> Subject: Re: [opus] OPUS on embedded platforms
> 
> Jean-Marc Valin wrote:
>> On 12/18/2012 09:35 AM, van Bijleveld Christian (ST-CO/ENG1.3) wrote:
>>>    * I see that there are projects which aim to implement OPUS on a ARM
>>>      processor. Does anyone know about or have figures regarding
>>>      resources (memory footprint, clock cycles) which are needed in
order
>>>      to run OPUS on lower-profile processors, such as Cortex Mx,
Blackfin
>>>      DSP or some TI DSP??
> 
> Just as a point of reference, a fixed-point build running complexity 10 
> encode+decode of 48 kHz stereo in CELT mode at 64 kbps is 3.3x realtime 
> on my 600 MHz Cortex A8 (which is not an Mx, but should at least give 
> you something to compare to). There's still substantial room for 
> platform-specific optimizations here.
> 
>>>    * If these figures are not available, does anyone have an estimate on
>>>      how many resources OPUS needs compared to the AAC codec??
> 
> Which AAC? HE-AAC requires well over 3 times as much CPU as LC-AAC.
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
>