Just an update ... The bleeding edge of opus development can now be found at: https://github.com/freqmod/rockbox-opus
I synced this to recent rockbox at: http://gerrit.rockbox.org/r/#/c/300 (this also shows the current issues) Currently, the main issues are: * Still needs too much stack for our codec thread * Seeking is implemented, but does not work for all cases * It's not realtime yet on portalplayer (e.g. sansa e200) last time I tried Regards, Bertrik On 26-7-2012 2:08, Bertrik Sikken wrote: > Hi all, > > Me (bertrik) and freqmod (Frederik M.J. Vestre) have been working on porting > a new codec to rockbox, the opus codec, see also http://www.opus-codec.org/ > This codec is backed by an IETF draft and I consider it as the next > evolution beyond vorbis and speex, with specific support for both music and > speech. It is wrapped in an ogg container, like vorbis and speex. > > The current development of the port can be found at: > http://gerrit.rockbox.org/r/#/c/300/ > freqmod also has a github repo (currently a few days older) at: > https://github.com/freqmod/rockbox-opus > > Stuff that works: > * Playback on both the simulator and on target > (tested on the Sandisk Sansa Clip Zip + simulator) > * Reading metadata (opus metadata is very similar to vorbis metadata) > * UI shows playback progress in the progress bar > > Stuff that still needs work: > * Memory allocation in the codec main is not fully consistent yet (probably > leaking some memory), so playing several files in sequence may not work > * Stack usage is still quite high, I've seen about 10k for music and 36k > for speech on the clip zip, our stacks are currently 10kB by default. > * Applying global gain from the opus audio file is not implemented > (not sure if replaygain is working) > * Seeking is not implemented yet. We have several codecs now using the ogg > container, I think it should be possible to share more ogg-stuff between > these codecs, like seeking. > * I used the latest release of libogg (1.3), it is a bit wasteful because > it does a lot of memcpy'ing when processing a stream, also it performs > CRC checks on the data. Apparently there is a libogg2, which avoids at > least the memcpy. > * There are still some warnings emitted from the compiler. > > Please try it out and help enhancing it further. > > Kind regards, > Bertrik Sikken > >
