The Opus codec becomes an IETF standard

[Posted September 11, 2012 by corbet]

The Mozilla Hacks blog announces that the Opus codec is now an official IETF standard; it is RFC6716. "Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video."

to post comments

Congratulation team Opus!

Posted Sep 11, 2012 19:36 UTC (Tue) by Tester (guest, #40675) [Link] (1 responses)

Now we're just missing a RFC for the RTP format to standardize the useful form.

Congratulation team Opus!

Posted Sep 11, 2012 19:58 UTC (Tue) by jmspeex (subscriber, #51639) [Link]

We're working on it. See http://tools.ietf.org/html/draft-spittka-payload-rtp-opus

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 19:39 UTC (Tue) by BrucePerens (guest, #2510) [Link] (10 responses)

There are patent disclosures with RAND terms and "possible royalty/fee" that aren't compatible with Open Source.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 19:46 UTC (Tue) by gmaxwell (guest, #30048) [Link] (5 responses)

These are inapplicable to Opus, anyone that wants can post statements.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 19:51 UTC (Tue) by BrucePerens (guest, #2510) [Link] (4 responses)

Hi Greg,

Anyone who wants can file lawsuits, too. I think it's fair to say these two companies are marking what they think is future territory for a lawsuit, and also attempting to assert treble damages for knowing infringement.

It's too bad they aren't interested in cooperating. Has there been much effort to lobby them?

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 21:03 UTC (Tue) by gmaxwell (guest, #30048) [Link] (3 responses)

There was, of course, a significant effort applied to ensure that Opus was free of these (and other) encumbrances. And the non-RF filings were not updated against future versions of the draft (but they aren't required to be so take that for whatever its worth).

My understanding from the communication we had from QC them was that their disclosure was purely driven by a employee viewing 100k foot level slides at IETF 77, and that they've never conducted any legal _or_ technical review whatsoever, never read the draft, and never looked at the code. They've filed IPR statements against a collection of other similar things, including SIP, Especially after the disclosure a lot of focus was applied by other people to make sure things were clear, something you can't say for SIP (QC's disclosure came many years after the standard was published).

(And now is when I eagerly await your posts on every comment thread about OSS SIP implementations on the net asking them the same thing)

It seems many companies have taken a conservative approach to the IETF IPR policies, with the concern that the IETF rules would be found by a court to bar enforcement of their patents unless they had filed a disclosure, so they broadcast file against anything that touches a space they have a commercial interest in.

Arguably this is a flaw in the IETF process... but when understood for what it is it can actually be quite helpful. If courts do eventually conclude that the disclosures are limiting, even if of just some parities, then even these promiscuous disclosures will greatly aid efforts to write royalty-free standards since they help focus on what review and clearance.

And, of course, if these parties to attempt patent extortion they'll lose their patent licenses to practice Opus from the actual authors. This is something that could be quite commercially expensive. I think the situation is pretty good, or otherwise I would have made sure that the standard was not published. IIRC, the only comments raised during the final consensus comment about the non-RF filings were people saying they were inapplicable.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 22:16 UTC (Tue) by BrucePerens (guest, #2510) [Link]

And now is when I eagerly await your posts on every comment thread about OSS SIP implementations on the net asking them the same thing

We're not driving the standards organizations in the right direction. The promotion of open-stand.org is especially disquieting, as the platform they've chosen says that RAND is OK, and even W3C got behind that.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 23:21 UTC (Tue) by tterribe (guest, #66972) [Link] (1 responses)

> If courts do eventually conclude that the disclosures are limiting...

Well, at least one court has already found that they are: http://www.mofo.com/pubs/xpqPublicationDetail.aspx?xpST=P...

My favorite part of that ruling being that this is true even if the disclosure rules are unclear, and even if they don't impose a duty to disclose at all (so long as the parties involved believe they do).

And if you look at the parties involved in that case, it may make their current "spray and pray" strategy a little more understandable, if not exactly appreciated.

But, yes, the best part about the IETF IPR policy is that, unlike the ISO or ITU policies used to produce video codecs, it requires disclosure of specific patent and/or application numbers up front, which prevents you from having to fight statements like, "All video codecs are patented."

RAND licensed patents with possible royalty/fee

Posted Sep 12, 2012 16:34 UTC (Wed) by BrucePerens (guest, #2510) [Link]

Thank you. I hadn't looked at these cases. Time to go to another IPR conference, I guess.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 20:07 UTC (Tue) by tterribe (guest, #66972) [Link] (2 responses)

Hi Bruce,

Please see the statement on Opus's royalty-free status from our previous article: https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/
I believe everything we said there was accurate and still applies.

We'd love to say a lot more about the IPR disclosures you referenced, but are still waiting for approval from our legal department. I'm sure you understand the difficulties with being allowed to say in public as much as we already have.

RAND licensed patents with possible royalty/fee

Posted Sep 11, 2012 20:20 UTC (Tue) by BrucePerens (guest, #2510) [Link]

Hi Tim,

I wrote to the appropriate people at Qualcom about this, asking for them to help to get the company on board. I don’t know anyone at Huawei.

I understand that you won’t be allowed to say anything without approval of counsel.

If companies that obviously make use of tons of Open Source software in their products take the stance that they will also attempt to encumber our work, we really should put some social pressure upon them. This is regardless of whether we think their patents are actually applicable or not – they are making the claim and should bear the cost of that.

Of course, we should allow some time for them to change their minds, or for private contacts to do their work.

But there should be a date beyond which we do something, if these declarations are unchanged.

I am happy to speak confidentially with any party, +1 510-4PERENS if you’d like to call.

RAND licensed patents with possible royalty/fee

Posted Sep 12, 2012 23:35 UTC (Wed) by ewan (guest, #5533) [Link]

It strikes me that if you're trying to convince people that this codec is free of sundry legal nasties, then "I can't even talk about it without my lawyer" is about the least confidence inspiring thing you could possibly say.

RAND licensed patents with possible royalty/fee

Posted Sep 12, 2012 7:47 UTC (Wed) by Seegras (guest, #20463) [Link]

So what, these patents are illegal anyway, since their validity is based upon total bogus reasoning ("Moby Dick Support Device")
http://scholar.google.com/scholar_case?case=4571960268239...
http://scholar.google.com/scholar_case?case=2299319819326...

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 20:41 UTC (Tue) by cyanit (guest, #86671) [Link] (8 responses)

Is Opus always better than Vorbis in practice, making Vorbis usage no longer recommended, or is Vorbis still useful beyond compatibility?

More in general, is Opus indeed the best audio codec ever for any sort of audio at more than 12 kbps (as the graph seems to show, although > 128 kbps is missing), or are there tests that show that something else beats it in certain situations?

What about efficient compression of surround audio, both for command formats, and for generalized surround with an arbitrary number of channels in arbitrary 3D positions?

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:03 UTC (Tue) by jmspeex (subscriber, #51639) [Link] (2 responses)

When you get to bitrates like 128 kb/s, it's so close to transparent that it's nearly impossible to test which codec is best with any kind of statistical significance. If you encoded all your music collection with Vorbis at 160 kb/s, I don't think you'd be gaining much from using Opus instead. Opus, Vorbis and AAC are so close to transparent at those rates that it's becomes mostly an encoder issue. In the end, there are bit-rates where Opus clearly outperforms Vorbis, but we're not aware of Vorbis really outperforming Opus at any point.

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:25 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

Web based Voice over IP and super-high-compressed video/music is were Opus should shine.

Can it usefully be embedded in webm?

The Opus codec becomes an IETF standard

Posted Sep 11, 2012 21:59 UTC (Tue) by bjencks (subscriber, #80303) [Link]

Not webm, since webm is specifically the matroska/vp8/vorbis combination, with some extra restrictions on what matroska features are available.
There's work on putting it into matroska, though it looks like there are some incompatibilities with seek timestamps: http://wiki.xiph.org/MatroskaOpus

The Opus codec becomes an IETF standard

Posted Sep 12, 2012 9:32 UTC (Wed) by Jonno (guest, #49613) [Link] (4 responses)

> Is Opus always better than Vorbis in practice, making Vorbis usage no longer recommended, or is Vorbis still useful beyond compatibility?

Opus was not designed to obsolete Vorbis, only Speex. However, as a happy accident it outperforms Vorbis for bit rates of 96 kbps and below. For higher bit rates, it is statistically tied with Vorbis, primarily because the difficulty of hearing any difference at all between Opus/Vorbis and the original.

So, for any use of low-bitrate Vorbis (or mp3), switch to Opus. For high bit rates, use Opus or whatever you did before, whichever is easiest for you. As I expect Opus compatibility to overtake Vorbis compatibility fairly soon, I would make any new encodes as Opus, at 128kbps if mono and 192 kbps if stereo. Anything above that is not really useful except for perfect fidelity, in which case you should just use Flac instead.

> More in general, is Opus indeed the best audio codec ever for any sort of audio at more than 12 kbps, or are there tests that show that something else beats it in certain situations?

Last I checked, Opus is either better or statistically tied with all competitors at all supported bit rates above 12 kbps, and statistically tied with the original at the maximum bit rate of 256 kbps per channel, but there might be some study I have missed.

> What about efficient compression of surround audio, both for command formats, and for generalized surround with an arbitrary number of channels in arbitrary 3D positions?

Opus only support stereo coupling, but you can add several stereo-coupled channels in one stream (eg 7.1 surround would consist of three stereo couplings and two discrete channels). Not optimal efficiency, but better than Vorbis (which doesn't support coupling at all when there is more than two channels), and generally speaking good enough.

Comparison with codec2 & other very narrow encoders?

Posted Sep 12, 2012 14:40 UTC (Wed) by ejr (subscriber, #51652) [Link] (2 responses)

It'd be nice to see a low-end version of the quality graph comparing Opus with codec2 ( http://www.rowetel.com/blog/?page_id=452 ) and other low-rate voice encoders. I realize they're different design points, but the comparison would give an idea of the trade-offs in bit rate v. overall use (not just voice) in the lower end.

Comparison with codec2 & other very narrow encoders?

Posted Sep 13, 2012 8:50 UTC (Thu) by jmspeex (subscriber, #51639) [Link] (1 responses)

The comparison is actually not helpful because Opus just doesn't go that low. As I've said before, the only two codecs that Opus does not replace are codec2 and FLAC.

Comparison with codec2 & other very narrow encoders?

Posted Sep 13, 2012 15:21 UTC (Thu) by ejr (subscriber, #51652) [Link]

It is helpful at a higher level. If you're trying to design a system, is it worth pushing the bit rate as low as possible? Seeing the qualities achieved for typical signals can help people decide which trade-offs to tackle. Should you shoot for jamming enough into single network packets with moderate lag and a simple overlapping scheme for handling drops or go ahead and expect many packets with a different error handling mechanism, etc.

The Opus codec becomes an IETF standard

Posted Sep 13, 2012 9:19 UTC (Thu) by tterribe (guest, #66972) [Link]

> Not optimal efficiency, but better than Vorbis (which doesn't support coupling at all when there is more than two channels), and generally speaking good enough.

Vorbis is actually the only format I know that supports arbitrary multi-level coupling. It simply wasn't implemented in a real encoder until 2010 (and the fact that it took that long speaks a lot more to the demand for this feature than the difficulty). And of course, when it was implemented, it broke decoders that hadn't bothered with that part of the spec.

See http://people.xiph.org/~xiphmont/surround/demo2.html for details.
The most interesting part of that work, to me, was that the bulk of the gains came from re-training the VQ backend, not from the coupling itself. Opus uses algebraic VQ which does not need to be re-trained.

The Opus codec becomes an IETF standard

Posted Sep 12, 2012 9:07 UTC (Wed) by xnox (subscriber, #63320) [Link] (1 responses)

And why did they not call it WebAudio surely that's the way to call "new" & "patent-unencumbered" codecs....

The Opus codec becomes an IETF standard

Posted Sep 13, 2012 11:03 UTC (Thu) by juliank (guest, #45896) [Link]

Shouldn't that be WebA then?