[CELT-dev] CELT/Opus Status Update
jmvalin at jmvalin.ca
Mon Aug 8 09:02:35 PDT 2011
On 11-08-07 09:30 PM, Brett Paterson wrote:
> 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.
There is definitely an increase in the overall footprint if you compare
Opus to CELT, though I wouldn't be able to say how much and I know that
some of that could be reduced. Of course, using Opus Custom would still
give you exactly the same footprint as you had with CELT.
> 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:
> 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.
> celt-dev mailing list
> celt-dev at xiph.org
More information about the celt-dev