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."
Obligatory.
Seems to cover a wide range of range applications. I wonder why they left out loseless encoding. That would have made it the one true codec for everything.
What's wrong with Bill the Cat?
A feeling of having made the same mistake before: Deja Foobar
Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.
Ezekiel 23:20
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
It's true that Opus does better than AAC and Vorbis at CD-quality bitrates and thus would be an improvement for music players etc.
But the improvements there are fairly small- in fact, Opus wasn't originally targeted at that kind of use at all, and the authors were quite surprised that it outdid those kinds of high-latency codecs. Opus is a very low-latency codec, and it combines Skype's speech compression technology and more music-oriented technologies (those introduced in CELT) to allow interactive speech and music over the Web.
Gaining marketshare in the high-bitrate stored music market against dominant formats like MP3 and AAC is hard, even when you outperform them substantially. But there's not really any established players in low-latency Internet audio. Opus blows all the other low-latency and/or low-bitrate codecs out of the water when competing in those other codecs' bitrate-latency "sweet spots", is the only codec which can compete across that kind of a range, is now a standard, is royalty-free, and is already implemented in Firefox.
Those who are saying "meh, only audiophiles will care" or "this won't get marketshare against AAC" are missing the point. This codec will change the face of the Web.
Audiophiles? Really? The only format they care about is original wax drums rubbed with a diamond and amplified by analog equipment connected by gold cables soaked in unicorn tears. They want nothing to do with digital audio codecs.
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:
still could use some love:
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)
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.
Opus: the Swiss army knife of audio codec
none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ https://datatracker.ietf.org/ipr/1741/ wherein we learn that Opus is "possible royalty/fee". this is not consistent with "Fully Free" to any patent troll waiting for broad adoption before jumping.
To me the biggest difference is that Vorbis was competing head on with a strongly entrenched codec (MP3) and it's official successor (AAC). Opus on the other-hand fills niche in the audio encoding world that doesn't have an established winner; that is high-quality low-latency codecs. This area has largely been driven by cellphone market, and has focused on encoding voice signals at toll-quality, that is as good as an analog long-distance signal (8kHz mono). There really hasn't been much focus on creating a low-latency codec that can encode full-band (music signals), and Opus does that incredibly well. It also sounds much better encoding speech at the bitrates that are used for VoIP (rather than the lower ones used by cellphones).
The internet community has never really been happy with the performance of ITU specified codecs that have been primarily used for SIP and other VoIP applications in the past, and there is no good reason from them not to support Opus. The patent grants are there, the vender support is there, and there is no real competitor codec worth mentioning. I'm convinced this will make much deeper inroads than Vorbis did.
For low bit rate voice (down to 1400bit/s) you can use codec2.
When applied to a codec, "latency" (obviously) refers to stream latency, not network latency (the latter has nothing to do with a codec, obviously). The problem with codecs like MP3 for streaming purposes is that they encode fairly large "frames" of audio, and these frames must be recorded before they can be encoded, encoded before they can be transmitted, received before they can be decoded, and quite possibly also decoded (fully) before they can be played. It may be possible to begin playing before the decoding is complete, which would help a lot, but it also might not - it depends on the codec.
Suppose you've got a "high latency" codec (such as MP3) that uses a 250ms frame and requires full decoding (this is an example; I don't know the actual numbers for MP3). Then suppose you have a low-latency codec (like Opus) with a 15ms frame size. In both cases, your network latency is going to be the same (let's say 100ms). You want to stream audio over this connection. It's pretty high bandwidth and you've got a decent audio processor, so any codec can be encoded, transmitted, and decoded in 10ms or less.
At t=0, begin recording an audio (such as voice) segment.
Codec1 (high-latency):
At t=250ms, you've filled the frame and can begin compression.
At t=360ms, the frame has been encoded, transmitted, received, and decoded.
Total latency before playback can begin: almost 3/8 of a second after recording began.
Codec2 (low-latency):
At t=15ms, you've filled an audio frame and can begin compression.
At t=125ms, the frame has been recieved and decoded by the other end, and playback can begin.
Total latency: 1/8 of a second over the same network connection.
1/8 of a second can be perceived, but barely, and almost all of that is simply an inherent cost of the network transmission. 360ms is not only easy to perceive, it's quite enough to be annoying (think intercontinental call via satellite). There's tons of demand for low-latency codecs.
There's no place I could be, since I've found Serenity...
Pffft, you say ordinary diamonds. real audiophiles only listen to BLUE diamonds that were polished on the thighs of virgins.
Do not look at laser with remaining good eye.
"Shine" is a really funny word for what HE-AAC sounds like at 16-24kbps. You can't polish a turd.
As far as AMR-WB/NB, you have to get down to 8kbps before AMR-WB sounds measurably better, and you have to get down to 6kbps before AMR-NB sounds better. Opus is tied with AMR-WB at 12kbps and better at 16kbps, and it's tied with AMR-NB at 8kbps and significantly better at 12 or above. Look at the studies linked from the comparison page if you want more details, keeping in mind that the Opus encoder has continued to improve in the year since those studies were done.
I asked Qualcom if they'd consider changing their declaration to royalty-free. I don't know anyone at Huawei.
Bruce Perens.
This is why you shouldn't let the DSP engineers comment in public. Opus only couples two channels at a time, but the multichannel support is at the internal codec framing level. Not the container level. Container level would be a disaster, as basically nothing would be able to support it without a redesign (apps not designed for sample accurate sync between separate streams), and there wouldn't be ways to signal the use or mapping in most containers.
RAND = reasonable and non-discriminatory
That means potentially including royalties, and there is no real definition of what is "reasonable" and "non-discriminatory". In general the presence of royalties discriminates against Open Source completely.
Bruce Perens.