with the 2 combined, is there any difference in runtime memory overhead for
codec memory footprint, either in per-codec state footprint, or the
background table sizes. Our biggest concern is runtime memory overhead and
cpu performance.
Brett Paterson | CEO
FMOD by Firelight Technologies Pty Ltd
Interactive Audio Middleware | www.fmod.org
PH: +61 3 96635947 Fax: +61 3 96635951
-----Original Message-----
From: celt-dev-bounces at xiph.org [mailto:celt-dev-bounces at xiph.org] On
Behalf
Of Jean-Marc Valin
Sent: Saturday, 6 August 2011 7:41 AM
To: celt-dev
Subject: [CELT-dev] CELT/Opus Status Update
Hi everyone,
I've made several posts recently about CELT being "replaced" by
the Opus
codec ( http://opus-codec.org/ ) and I thought it was time to give an
update on what's going on.
As many of you know, I've been involved at the IETF on this new Opus
codec, which essentially merge (a modified version of) Skype's SILK
codec with CELT. This is more than just two codecs with a big switch.
For example, it's now possible to have very high quality full-band (48
kHz) speech at 32 kb/s -- something neither SILK nor CELT could
originally do.
So for the past three months, the actual repositories have been merged
into a single repository git://git.opus-codec.org/opus.git and no code
is being checked into the original CELT repository. During last week's
IETF meeting, the final details of the Opus bit-stream have been agreed
on and there should be a (second) working group last call in 3-4 weeks.
After this, it goes to IETF last call and (hopefully!) RFC.
I'm aware that some people here are not interested in the aspects that
SILK brings, but only to the low-delay aspect or other special features
(e.g. various frame sizes) of CELT. All of this will remain possible
through the use of "Opus Custom" modes. These modes will not
inter-operate with the "normal" Opus modes, but will keep all the
features and flexibility that were available in CELT. I would still
recommend most people use the normal modes as they provide much better
interoperability (e.g. you can stream Opus packets with no out-of-band
signalling), but for those who absolutely need (e.g.) power-of-two frame
sizes, Opus Custom will be there and work exactly like CELT did.
At this point there are still a few rough edges with the merging of the
code, but it's getting better. As some may already know (e.g. from my
blog) I have just been hired by Mozilla to work on codecs, so I should
have a lot more development time than previously. One of the first
things I've been working on is tools for Opus in Ogg and (in general)
finalizing the Ogg mapping. The git repo for the tools (sorry, no build
system yet) is at:
http://git.xiph.org/?p=users/jm/opus-tools.git;a=summary
Note that the current Ogg mapping used by opusenc/opusdec is *not* final
and will likely change before it is frozen (hopefully very soon). We're
interested in feedback on the current mapping.
The last point is IPR. Yes, there are patents, but they have all been
licensed royalty-free as soon as Opus gets adopted by the IETF (i.e.
RFC), which should happen soon. We're also working on getting the
licenses changed so that they also apply to the pre-RFC draft. In the
mean time I encourage everyone to test Opus and report any problem.
Hope this answers most questions.
Jean-Marc
_______________________________________________
celt-dev mailing list
celt-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/celt-dev