It’s Opus, it rocks and now it’s an audio codec standard

There is no such thing as "unencumbered by patents". Unless you have a technology that has already been tested thoroughly in the courts, which is the only way you can really determine whether something would be deemed to violate a patent or not, you simply can't know.

I don't know which XKCD strip you're referring to; link?

> And here's the coolest part of the article that completely took me by surprise: "The IETF recently decided with “strong consensus” to adopt Opus as a mandatory-to-implement (MTI) codec for WebRTC, an upcoming standard for real-time communication on the web."

Indeed. There may be interesting side consequences for that. The first article comment asks:

> Interesting! Any idea if this will become mandatory to implement for HTML5 audio as well? That’s another area in sore need of a single format that works everywhere.

This means that if a browser supports WebRTC, it has to support Opus, and it then happens that the codec will be available for <audio>. Now that does not mean that <audio> => Opus support, but it will have a (increasingly with time) high chance to be so.

> Using low bit rate Opus may yield a 3MB file for a song, were as FLAC may end up being 150MB for the same audio.

3MB will get you POTS-quality audio though. Lossless codecs usually compress audio to half the original size (so a 150MB FLAC file — for music — will correspond to ~300MB of raw bitstream). Lossy compression to something worth listening to will usually be around 10x compression, so ~30MB for an original 300MB bitstream.

A 35mn song compressed in 3MB probably won't be worth listening to.

There was no existing codec that is both good and not encumbered by patents.

Opus is good and not encumbered by patents, and it has just been standardized.

X = {voip, videoconferencing}

Say you wanted to write a live audio chat app to talk to your friends. If you'd chosen the Speex codec, then voice would come over fine, but trying to show off your new guitar skills would fail because what they heard would sound horrible.

If you'd chosen the Vorbis codec, then everything would sound great, but there'd be a weird "lag" between participants, as if one of them were on the moon. Also, adding too many listeners would severely strain your internet connection's capacity.

Opus has latencies as good as Speex, and can be high-, medium-, or low-quality depending on bandwidth needs.

Look at the graph in the article. Opus is as good as or slightly better than all the existing codecs at their strong points, and much better than them at their weak points.

While MS might not take full advantage of it, IE 10 will have silent updates. I would hope that would mean they drop the monolithic update strategy.

The article mentions that Skype was a party to the standardization process, and hence Microsoft by association. So there's a small reason to hope.

> I expect Firefox and Chrome to adopt this within months,

Firefox already adopted it (it's in nightly builds). Chrome seems to have WontFixed it,

http://code.google.com/p/chromium/issues/detail?id=104241

It is absolutely able to dynamically adapt based on bandwidth, and is robust to packet loss. It was designed for that :)

http://www.opus-codec.org/ https://wiki.xiph.org/OpusFAQ

> Can someone tell me if it is able to dynamically adapt quality based on available bandwidth?

Depends on what you mean. It is a variable bitrate codec, and the encoder can easily adjust the bitrate of the stream. But you would need a way to discover the available bandwidth and communicate it to the encoder - Opus is just a codec, not a container or streaming protocol.

> If it loses packets in the stream, do we get a 'skip' in the audio or does the quality go down?

The standard doesn't mandate a specific way to deal with packet loss, but the reference implementation tries to handle this gracefully. [1]

Some properties of the encoding facilitate this: for instance, packets can optionally include a reduced-bitrate encoding of the previous packet to provide redundancy. [2]

[1] http://tools.ietf.org/html/rfc6716#section-2.1.8

[2] http://tools.ietf.org/html/rfc6716#section-4.4

Yes, it's absolutely made for that, which is one of the reasons it has extreme bitrate and frame size agility. Though the decoder doesn't have a back channel to the encoder as part of the format (e.g. a duplex pair is not at all coupled by the codec and could have entirely different settings). So if you want to do rate adaptation the application will have to take care of telling the encoder that the decoder is struggling/losing frames/etc.

The codec also includes a pretty good packet loss concealer integrated, and can also use forward error correction to reduce the impact of loss.

It actually includes code from Celt and merged with code from Silk (the Skype codec).

Silk is very good at speech and Celt is very good at music. It is like having gears in your car. You need low gears for one mode of operation and high gears for another. So they combined the two into one and made a single codec.

I imagine behind the scenes it has a transition mode from one codec to another depending on the configuration parameters.

The final version of libcelt is bit-for-bit compatible with Opus. Unlike SILK, there was never a "stable" version of CELT (we routinely broke the bitstream on almost every commit), so CELT development continued after the two codecs were merged, right up until the Opus bitstream was frozen.

That makes Opus a strict superset of CELT, and we've stopped maintaining libcelt, so any existing users should switch to libopus.

Why would you say that?

Most "hardware" decoders are DSPs that run software loaded onto them at runtime. This goes for anything with an OMAP, Tegra or Samsung (Samsung's own decode block) SoC in (that I know for sure) and probably almost everything else. Tegra3 and OMAP4 can decode WebM in hardware, for example.