Rockbox Development > Feature Ideas
CELT/Opus Codec
gmaxwell:
Opus is done, the standard has been approved and is going through its final purely-editorial revisions. Support exists in Firefox (nightly and aurora) in the audio tag, gstreamer, and is now available in many GNU/Linux distributions. Support in ffmpeg and foobar2000 is coming soon.
Support in rockbox would be fantastic, and the Opus developers would be glad to answer questions and solve any issues that come up.
saratoga:
--- Quote from: gmaxwell on July 14, 2012, 10:52:38 AM ---Support in rockbox would be fantastic, and the Opus developers would be glad to answer questions and solve any issues that come up.
--- End quote ---
I don't have time for another project at the moment, but I did take a look at the source code. One concern I have is all of the malloc/free calls. Since we don't have MMUs, we can malloc, but have only limited ability to free. Does the codec do malloc/free calls during decoding, or only during init/clean up? How feasible would allocating worst-case memory be in place of malloc?
gmaxwell:
No malloc/free is performed during decode (or encode for that matter) itself. ... or, if you want, at all:
There are get_size() calls that tell you how much memory the decoder will need. If you allocate a contiguous block of at least that much and call _init() on it, you're good to go. The required memory only depends on the channel count (and stream count in the case of surround support), and all streams can be decoded as stereo.
A little more complicated is the stack handling. Part of the code uses alloca or var-arrays for data on the stack. If these aren't available it can also be compiled in 'pseudostack' mode which just uses a static array for its variable stack usage, all compile time options. This third option is generally discouraged because its not threadsafe. ... which is probably not an issue for rockbox.
The code has been tested on pretty limited platforms, including MMU-less ones... so there shouldn't be fundamental there. While it was previously running on TMS320c55 (where int==short==char==16bits) platforms where int is 16 bits are probably bitrotted at the moment and probably have some bugs.
wodz:
Basically all platforms on which rockbox runs have int >= 32bits and short >= 16bits so this should be no issue.
jxself:
--- Quote from: Llorean on April 12, 2011, 10:42:46 PM ---It also wouldn't make much sense until the codec reaches 1.0
--- End quote ---
I just wanted to point out that 1.0 is out now.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version