Slashdot Mirror


Opus — the Codec To End All Codecs

New submitter jmv writes "It's official. The Opus audio codec is now standardized by the IETF as RFC 6716. Opus is the first state-of-the-art, fully Free and Open audio codec ratified by a major standards organization. Better, Opus covers basically the entire audio-coding application space and manages to be as good or better than existing proprietary codecs over this whole space. Opus is the result of a collaboration between Xiph.Org, Mozilla, Microsoft (yes!), Broadcom, Octasic, and Google. See the Mozilla announcement and the Xiph.Org press release for more details."

7 of 327 comments (clear)

  1. It's awesome by LSD-OBS · · Score: 5, Interesting

    About 9 months ago, I implemented Opus in our VoIP products, replacing G722 and Speex. It kicks a whole lot of ass. Compared to speex, It's far better coded, uses far fewer CPU cycles, and sounds vastly better (even to me, and I have shitty hearing). Similarly, we replaced all our old audio DSP pipeline, based on the Speex library (thanks Xiph.org, etc) with the low-level components from WebRTC (thanks Google!) and things have never sounded better.

    --
    Today's weirdness is tomorrow's reason why. -- Hunter S. Thompson
  2. Getting it right the second time! by bill_mcgonigle · · Score: 4, Interesting

    Kudos to the folks working on this. We were all rooting for ogg/vorbis/xiph, but they had some lessons to learn. Positives that I see for Opus:

    • libopus is available now
    • it has an integer-only compile flag
    • it's BSD licensed
    • patent grants from big industry players
    • doxygen API docs
    • big open source projects already support it
    • orchestrated PR

    still could use some love:

    • apparently it's CPU/power efficient but that's not bragged about (and many would suspect otherwise).
    • some of the documentation is just a link to slide decks from conferences
    • there is test code, but I didn't see sample code explicitly. Yeah, you can grab ffmpeg source or whatever, but purposeful sample code is written to be as explanatory as possible. Maybe it's in the tarball, but if it is, say so on the download page.

    Still, an order of magnitude better than the last attempt at gaining industry acceptance of free codecs. This one might just work out!

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  3. Re:Sorry, nope. by jmv · · Score: 4, Interesting

    Bitrates below 16 kb/s are irrelevant on the Internet. Just the overhead (IP+UDP+RTP headers) of sending packets every 20 ms is 16 kb/s. At that point, you might as well transmit some real quality.

  4. Re:Obligatory by Teancum · · Score: 5, Interesting

    What would make an audio codec something worth using that would make you switch?

    I would assume that widespread support among major applications would be an issue. You could also throw in the ability to compact an audio stream better than alternatives might be useful in some applications. Simply having content in that codec would be very useful as well.

    I would say being patent and license free (aka it can be incorporated into a GPL'd application) would be pretty far down the list, but not needing to pay a licensing fee might make the difference for some marginal applications or for start up groups needing some sort of audio playback where even a few extra dollars in royalties can end up costing more than it is worth (such as is the case for the current MP3 format).

    Then again that is sort of what pushed the VHS format over Betamax in the video tape format wars.... small independent producers could mass produce VHS tapes cheaper than the Betamax tapes, and for marginal videos (*cough* porn movies *cough*) that made all of the difference.

    The problem here is that audio codecs are pretty entrenched and as you've suggested that even free alternatives are available. Unless there is something substantially different being done by this codec that even a non-techie can notice and suggest that this new algorithm is substantially better, I really have a hard time seeing this being adopted widely. There might be some niche applications if the compression algorithm is even a few percentage points better, such as perhaps a transmission protocol for audio on the Iridium satellites. Something like that may even be useful to have an on the fly codec converter depending on how it is used.

  5. Re:No Loseless support? by ZorinLynx · · Score: 4, Interesting

    Actually generic data compression algorithms don't work very well on audio files. Lossless audio codecs like ALAC and FLAC do waveform analysis and "know more" about the nature of audio files so that they can be compressed more than your typical compression algorithm like gzip would do.

  6. Re:No Loseless support? by jmv · · Score: 5, Interesting

    I don't think silicon support for audio codecs is really useful anymore. Audio codecs have such a low complexity compared to video that modern smartphones can run them really easily.I haven't measured exactly, but I'd say you can probably decode an Opus stream with about 2% CPU on the latest Android phone. Not worth paying for extra silicon.

  7. Re:Some indications that it's not "Fully Free" ... by Bruce+Perens · · Score: 5, Interesting
    The developers are adamant that the patents claimed by Qualcom and Huawei don't apply to their code. But at the moment, those two companies are claiming their patents could apply, and are asking for RAND terms with possible royalties.

    I asked Qualcom if they'd consider changing their declaration to royalty-free. I don't know anyone at Huawei.