×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Opus — the Codec To End All Codecs

Soulskill posted about a year and a half ago | from the sounds-like-work dept.

Software 327

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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

327 comments

Obligatory (4, Funny)

Anonymous Coward | about a year and a half ago | (#41306161)

Obligatory. [xkcd.com]

Re:Obligatory (5, Funny)

plover (150551) | about a year and a half ago | (#41306193)

That's the nice thing about standards. There are so many to choose from!

Re:Obligatory (2, Insightful)

93 Escort Wagon (326346) | about a year and a half ago | (#41306375)

Yup, that was my thought the moment I read this - and I bet it was the case for a large number of other Slashdotters as well.

As far as being "good or better than existing proprietary codecs" go... I'll wait and see what people less invested in Opus say. We heard the exact same things about WebM, and the various Oggs before that - and it turned out not to be the case, unless the "Free" status of a codec was given significant weight in the quality space.

Re:Obligatory (5, Informative)

jmv (93421) | about a year and a half ago | (#41306925)

See the "listening tests" part of our comparison page [opus-codec.org]. These are all tests that were performed by other folks, independently from us.

Re:Obligatory (1)

Anonymous Coward | about a year and a half ago | (#41306969)

There are plenty of third party tests already, though I expect the one you'd be most interested in is: http://listening-tests.hydrogenaudio.org/igorc/results.html

Mozilla mentioned that XKCD comic in one of their own blog posts in fact!

Re:Obligatory (5, Interesting)

Teancum (67324) | about a year and a half ago | (#41307009)

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.

Re:Obligatory (5, Insightful)

Lumpy (12016) | about a year and a half ago | (#41307157)

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

A car stereo that supports it, phones that support it, etc... There is a reason that mp3 is still the king, it can be played on 98,543,221.5 different brand sof devices and another 800 are created that support mp3 every 6 seconds.

Ogg? 5 devices.
Apple's codec? 5 devices.

mp3 will be around for another 10 years simply because I can buy a $0.25 chip and make the toaster my company is making play mp3's.

No Loseless support? (3, Insightful)

ThatsMyNick (2004126) | about a year and a half ago | (#41306167)

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.

Re:No Loseless support? (0)

Anonymous Coward | about a year and a half ago | (#41306217)

Generally, there's no way to keep Anons from losing.

Re:No Loseless support? (2, Interesting)

Anonymous Coward | about a year and a half ago | (#41306261)

FLAC mainly, same reason that is it not replacing codec2 either.

http://www.youtube.com/watch?v=iaAD71h9gDU

Re:No Loseless support? (2)

Intropy (2009018) | about a year and a half ago | (#41306427)

They mention FLAC about 7 minutes into that video for anyone looking for it. They don't say much other than that they aren't trying to replace codecs for lossless (FLAC) or very low bitrate (codec2).

Re:No Loseless support? (5, Funny)

plover (150551) | about a year and a half ago | (#41306341)

They also left out n-channel support. You get mono or stereo, but that's it. No 7.1 surround encoding. That would have made it the one true codec for everything. That and lossless encoding. The two true codecs for everything.

Oh, and support in the iPhone. That would have made three true codecs. Among the many true codecs... oh bugger, I'll start again.

Re:No Loseless support? (4, Insightful)

Volanin (935080) | about a year and a half ago | (#41306429)

Opus has support for up to 255 channels [wikipedia.org]. Indeed, lossless was the most glaring omission, but considering the obsolescence of MP3HD [wikipedia.org], I think they must had good reasons to leave it out.

Re:No Loseless support? (4, Informative)

Anonymous Coward | about a year and a half ago | (#41306713)

Despite what the wiki page says, the RFC page states mono or stereo, and indeed the reference source code checks for channels equal to 1 or 2.

      if((Fs!=48000&&Fs!=24000&&Fs!=16000&&Fs!=12000&&Fs!=8000)||(channels!=1&&channels!=2)||
              (application != OPUS_APPLICATION_VOIP && application != OPUS_APPLICATION_AUDIO
              && application != OPUS_APPLICATION_RESTRICTED_LOWDELAY))
      {
            if (error)
                  *error = OPUS_BAD_ARG;
            return NULL;
      }

I think the 255 reference was probably a left over from the Vorbis definition. It's too bad that multi-channel isn't naively supported, as multiplexing multiple mono or stereo streams will be a bit of a pain.

Re:No Loseless support? (2, Informative)

Anonymous Coward | about a year and a half ago | (#41306757)

At least it looks like they thought of that and provided some helper code in the reference source. See opus_multistream.c / .h.

Re:No Loseless support? (0)

Anonymous Coward | about a year and a half ago | (#41307121)

Oh, and support in the iPhone

If it's a free unencumbered format, it can be supported in the iPhone, I should think. Apple is welcome to use it.

Re:No Loseless support? (2)

Tablizer (95088) | about a year and a half ago | (#41306379)

I wonder why they left out lossless encoding.

Because the specification was recorded on a lossy medium.

Re:No Loseless support? (1)

iluvcapra (782887) | about a year and a half ago | (#41306409)

Seems to cover a wide range of range applications.

Except surround sound. Or any spatialized content aside from L-R. Or synchronization with video, or any other kind of stream.

Also their list of uses are all streaming/interactive, like teleconferencing; the standard does not specify a recommended container format. Vorbis, FLAC and MP3 all have prescribed at-rest file formats.

Re:No Loseless support? (3, Informative)

iluvcapra (782887) | about a year and a half ago | (#41306535)

(comment withdrawn)

Re:No Loseless support? (-1)

Anonymous Coward | about a year and a half ago | (#41306621)

How can one withdraw/edit a comment? Or is this a troll/fake?

Re:No Loseless support? (1)

Anonymous Coward | about a year and a half ago | (#41306819)

How can one withdraw/edit a comment? Or is this a troll/fake?

Score: -1 (Retarded)

Re:No Loseless support? (5, Informative)

jensend (71114) | about a year and a half ago | (#41306709)

It can support up to 255 channels. The two-channel maximum is per stream. Multiple streams can be packed into single frames, but for >2 channels the mapping and coupling has to be signaled at the container level.

The standard tools available at opus-codec.org use Ogg as a container for "at-rest files," and Firefox, foobar2000, and gstreamer-supporting apps (like Opera on Linux) all play Opus-in-Ogg files. VLC and Rockbox will soon release versions with playback support for these too. Though RTP etc is a primary focus, the "at-rest file" support is ahead of the interactive support at this stage of the game.

A Matroska mapping is still in progress. Most likely, for the time being, Opus files will be predominantly Ogg, while the Matroska mapping will be more important for using Opus with video streams (esp. vp8, improving on the webm vp8+vorbis+matroska combination).

Re:No Loseless support? (4, Informative)

jmv (93421) | about a year and a half ago | (#41306851)

the standard does not specify a recommended container format

See the Opus Ogg mapping [ietf.org] for more details. Of course, if people want to use other containers, we're not a container police.

Re:No Loseless support? (1)

johnsnails (1715452) | about a year and a half ago | (#41306923)

Is that a new sig or do you change your sig based on what you happen to be commenting on at the time?

Re:No Loseless support? (0)

jmv (93421) | about a year and a half ago | (#41307065)

Haha! I've actually had that sig for about a year now.

Re:No Loseless support? (1)

Kaz Kylheku (1484) | about a year and a half ago | (#41307127)

Sync with video? What?

Raw waveform data can be synced with video.

Just say: one video frame = so many audio samples (at such and such a sample rate).

Re:No Loseless support? (2)

tlhIngan (30335) | about a year and a half ago | (#41306541)

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.

A quick look at the graph shows that they stop at 128kbps, which would mean it's a great codec for high-quality real-time audio telephony rather than as a codec to span the spectrum of low end real time to lossless audio.

At least looking at the page - the summary mentions it's the "one codec to rule them all", but the page leads me to believe it's something you'd use for say, teleconferencing and VoIP more so than multichannel lossless high-definition audio.

Perhaps they intend it to work reasonably well in all cases, but it looks like testing was done only to low-bitrate encodings of 128kbps and lower. At which point it looks like yes, for that scenario, it's the best.

Re:No Loseless support? (3, Informative)

jensend (71114) | about a year and a half ago | (#41306863)

Testing that things work has been done for all kinds of bitrates (512kbps per stream * multiple streams in a surround encoding). It's just that Opus is transparent to most listeners on most samples before you hit 128kbps for stereo. It's extremely hard to do a worthwhile listening test when only a few listeners can tell even a few of the samples from the original.

Some people at hydrogenaudio.org have reported problem samples which they were able to ABX from the original at up to 160kbps. I haven't personally found any stereo samples I can reliably ABX from the original at above 80kbps.

Of course lossless has its place. You don't want to be doing a lot of decoding lossy files, editing them, and then re-encoding, since you'll get . For similar reasons, rather than transcoding from one lossy format to another it makes sense to keep a lossless master and encode to lossy formats from that. But for listening purposes, Opus is quite capable of being perceptually transparent. [wikipedia.org]

Re:No Loseless support? (4, Informative)

jmv (93421) | about a year and a half ago | (#41306891)

A quick look at the graph shows that they stop at 128kbps, which would mean it's a great codec for high-quality real-time audio telephony rather than as a codec to span the spectrum of low end real time to lossless audio.

The reason the graph stops at 128 kb/s is that things become uninteresting at that point -- because nobody's able to actually tell the difference. With VBR, we've never had anyone report audio not being transparent above 200 kb/s. There's a reason people don't want to organize listening tests at 128 kb/s and (especially) above. It's indeed the case that we don't support lossless. That one is already covered very well by FLAC and there was no point adding completely different algorithms to handle that. Otherwise, Opus can replace MP3/AAC/Vorbis at rates above 128 kb/s too.

Re:No Loseless support? (3, Interesting)

Em Adespoton (792954) | about a year and a half ago | (#41306999)

I noticed there were no hardware manufacturers of note on the supported list -- are you planning to get chip-based support for Opus (so that it'll be handled transparently by all the phones etc out there, including, say Apple)?

Re:No Loseless support? (4, Funny)

sconeu (64226) | about a year and a half ago | (#41306997)

One Codec to rule them all
Once Codec to find them
Once Codec to bring them all
And in the RIAA's darkness bind them

Re:No Loseless support? (2, Informative)

Kaz Kylheku (1484) | about a year and a half ago | (#41307105)

Lossless isn't audio encoding; it's data compression like Lempel-Ziv 77 and so on.

Support for such a thing would mean that Opus is not a codec, but a container/stream format which multiplexes completely different compression algorithms.

Those, we probably don't need any more of.

What's Opus a BBS? (-1)

Anonymous Coward | about a year and a half ago | (#41306219)

Something like Opus CBCS? I think it gave us Avatar (a more condensed format than ansi/ascii).

And in other news (-1)

Anonymous Coward | about a year and a half ago | (#41306233)

Apple continued its support of its non-standard audio codecs and ignored Opus, leaving it to die on the vine.

Re:And in other news (-1)

Anonymous Coward | about a year and a half ago | (#41306365)

AAC is about as standard as you can get.

Oh boy! (-1)

Anonymous Coward | about a year and a half ago | (#41306281)

Another barely supported audio format that only audiophiles care about! Where can I sign up?

Re:Oh boy! (5, Insightful)

Russ1642 (1087959) | about a year and a half ago | (#41306671)

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.

Re:Oh boy! (0, Redundant)

Anonymous Coward | about a year and a half ago | (#41306829)

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.

Not any more. Have a look at a few audiophile forums - some have sections devoted to setting up high quality systems to play high bitrate audio files encoded in (eg) FLAC or Apple Lossless (whatever it's called). There's products like Pure Music that improve iTunes playback considerably and can import FLAC into iTunes. And very high quality USB sound cards for laptops eg CEntrance DACPort.

Patents (4, Insightful)

K. S. Kyosuke (729550) | about a year and a half ago | (#41306305)

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

Re:Patents (1)

ackthpt (218170) | about a year and a half ago | (#41306385)

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

File patent-troll suits proactively, a-la-The Minority Report, "Our mutants predict you will be violating our property rights in 5 years, so you can start paying now."

Re:Patents (1)

Anonymous Coward | about a year and a half ago | (#41306913)

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

Without patents, how long would the status quo have been "good enough" before people invested the time and money into something better as they have done here?

Yay! (1)

Anonymous Coward | about a year and a half ago | (#41306347)

Can't wait to try this on my portable music player!

Re:Yay! (1)

Anonymous Coward | about a year and a half ago | (#41307165)

Same here... mine's Android based, so I hope codecs will appear pretty soon.

Sorry, nope. (2)

Guspaz (556486) | about a year and a half ago | (#41306405)

be as good or better than existing proprietary codecs over this whole space

Except upon clicking on that link, their own graph is showing that it's not as good for anything under ~12 kbps or so, when compared to AMR-WB and AMR-NB. Furthermore, they have no data on HE-AAC below 64 Kbps, when in fact HE-AAC only really starts to shine at substantially lower bitrates like 16-32 Kbps. Bitrates in the 4-16 range are particularly relevant since you see a lot of voice communication down there.

Re:Sorry, nope. (-1)

Anonymous Coward | about a year and a half ago | (#41306703)

it's not as good for anything under ~12 kbps

Seriously?! Is that all you can moan about, that's below 1920's telephone quality. What is your problem? Oh, I see, you're an Apple zealot, you can't accept anything until your HIV+ cult leader tells you to. Got some bad news for you...

Re:Sorry, nope. (0)

Anonymous Coward | about a year and a half ago | (#41307071)

Nothing Guspaz wrote had anything to do with Apple and virtually everything you said was utter nonsense. Complete, embarrassing troll failure on your part there, buddy. Sour about that.

(hint #1: AAC does not stand for Apple Audio Codec. It wasn't developed by Apple. Its development wasn't even prompted by Apple. AAC is an industry standard codec developed as a higher quality successor to MP3; it's a part of the MPEG-4 standard. Apple's merely one of many users.)

(hint #2: you'd be shocked how few kilobits your cellphone allocates to voice calls. 12 is somewhat luxurious!)

(hint #3: a modern voice-optimized audio codec given 12 Kbps to work with might well deliver quality equivalent to a 1920s telephone call, or better. The public switched telephone network (PSTN) uses uncompressed 8-bit PCM at 8KHz, or 64 Kbps, a data rate chosen back in the 1960s with the goal of being good enough for users to not notice any significant degradation in quality compared to the old end-to-end analog signaling. 12K is only about 5:1 compression of that rate.)

Re:Sorry, nope. (4, Interesting)

jmv (93421) | about a year and a half ago | (#41306791)

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.

Day Tripper. Day Trader. (-1)

Anonymous Coward | about a year and a half ago | (#41306417)

You never see the two togther, ever. I think they are one in the same. Whatsay we kill one, and if the other shows up, we were wrong. If he never shows his face, these two were in fact, the SAME. Either way, we put an end to this problem, once and for ALL.

It's awesome (5, Interesting)

LSD-OBS (183415) | about a year and a half ago | (#41306433)

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.

Re:It's awesome (0)

characterZer0 (138196) | about a year and a half ago | (#41306785)

sounds vastly better (even to me, and I have shitty hearing)

Then maybe you are not qualified to determine if it sounds vastly better.

Re:It's awesome (1)

LSD-OBS (183415) | about a year and a half ago | (#41306861)

/* Not sure if trolling, or just not good at reading */

Re:It's awesome (0)

Anonymous Coward | about a year and a half ago | (#41307051)

But he's right, people with hearing defects may not be in a position to judge the audio quality of a codec, since they may not even perceive the "important" bits of the sound, which for "normal hearing" people would have masked some encoding noise. Therefore it would be possible that the "vastly better" codec just shifts the noise into frequency regions where he just can't hear them, while they may be very annoying or just obviously different from the original sound for the average listener.

Re:It's awesome (1)

LSD-OBS (183415) | about a year and a half ago | (#41307149)

The key word is "even". "even to me". Implying (but obviously too subtely for some) that my opinion of the sound quality is in agreement with the opinions of others. In this case, several dozen others. Unanimously.

Furthermore, I never said how shitty my hearing was. My version of shitty is having a hard time discerning between 160kbps and 192kbps mp3s, which several of my more keenly perceptive friends are able to do.

Re:It's awesome (1)

LSD-OBS (183415) | about a year and a half ago | (#41307163)

(And in case that hasn't cleared things up enough, let me say that the difference between Speex on highest quality and Opus, even on its lower quality settings, is like night and day)

Re:It's awesome (1)

Twinbee (767046) | about a year and a half ago | (#41307087)

He means he cant easily discriminate between the two, not that his ears distort things (or undistort them as the case may be).

Re:It's awesome (3, Insightful)

Kaz Kylheku (1484) | about a year and a half ago | (#41307155)

Umm, no. The more subtle the difference, the better hearing you need to be able to resolve an AXB comparison. (Is sample X equivalent to A, or equivalent to B).

If you can hear a difference with poor hearing, then it must be substantial.

What about APT-X (0)

midgetpoker (1148901) | about a year and a half ago | (#41306473)

The codecs being compared don't include APT-X which (in various flavours) is lossless, as close to realtime as makes no difference and has been used for everything from high-end rack mounted kit in TV studios down to being embedded in wireless microphones and bluetooth headsets.

Re:What about APT-X (1)

sexconker (1179573) | about a year and a half ago | (#41306663)

Real-time codecs have shitty compression ratios, though, because they can't compress temporally.

Re:What about APT-X (2)

jmv (93421) | about a year and a half ago | (#41306967)

Last I checked, APT-X was not lossless (you can't be lossless and guarantee a compression ratio). Also, the only time I saw a comparison between APT-X and Opus, Opus was actually winning hands down. APT-X claims compression ratios of 4:1 (so 384 kb/s for 48 kHz stereo). Opus is already transparent long before that. I've never had anyone telling us he could hear any kind of artefact whatsoever above 200 kb/s VBR). Usually, 128 kb/s (12:1) is transparent for the vast majority of content and listeners (yes, there are a few exceptions at that rate).

Many people missing the point: HTML5, VOIP, etc (5, Informative)

jensend (71114) | about a year and a half ago | (#41306481)

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.

Re:Many people missing the point: HTML5, VOIP, etc (-1)

Anonymous Coward | about a year and a half ago | (#41306571)

This codec will change the face of the Web.

How about the ass of the web, the pr0n business? What will be the impact there?

Re:Many people missing the point: HTML5, VOIP, etc (1)

Anonymous Coward | about a year and a half ago | (#41306777)

Don't be surprised if they are the first ones making a mass usage of it, streams, cams.

Re:Many people missing the point: HTML5, VOIP, etc (0)

Anonymous Coward | about a year and a half ago | (#41306685)

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.

Great but if there are no ASICs to decode it it will never be used in music players.

Those who are saying "meh, only audiophiles will care" or "this won't get marketshare against AAC" are missing the point.

The point being adoption, no? So how exactly are they missing the point? A great standard is meaningless with no one using it.

This codec will change the face of the Web.

Yeah, so was WebM, WebP, etc. Get widespread support first before declaring victory and what it will supposedly do.

Re:Many people missing the point: HTML5, VOIP, etc (0)

Anonymous Coward | about a year and a half ago | (#41306895)

You didn't actually read the GP, did you? If it lives up to the promises in the summary and article, it will get implemented because it will actually be cheaper to implement than the competing standards (due to requiring less computation and therefore less battery power). I assume ASICs will be needed for battery-efficient use on phones for use as a VOIP codec, but it can get plenty popular as a VOIP codec for desktops (and possibly implemented in software on phones initially). The GP already pointed out that no one is going to bother using Opus for music files because the improvement is negligible for that application, although since a lot of digital music players these days are smartphones, they will probably support such files in the future due to needing the Opus support for VOIP anyway.

Re:Many people missing the point: HTML5, VOIP, etc (1)

Wraithlyn (133796) | about a year and a half ago | (#41306839)

Opus is a very low-latency codec [...] to allow interactive speech and music over the Web.

Very good post, but I think you have your terms backwards? The web is a HIGH latency medium. Local storage on an MP3 player would be LOW (damn near zero) latency.

Latency = delay, not speed.

Re:Many people missing the point: HTML5, VOIP, etc (1)

bananaquackmoo (1204116) | about a year and a half ago | (#41306949)

No he is using RELATIVE measurements. This codec would be lower latency than other codecs when used on the internet.

Re:Many people missing the point: HTML5, VOIP, etc (1)

gnoshi (314933) | about a year and a half ago | (#41306981)

No, the terms are right: it is low latency in that it doesn't *add* much latency, which is a critical feature in bidirectional real-time communications (like Skype). Having a low-latency codec is even more important for the Internet, because of the existing latency you have pointed out which is cumulative with any delays introduced by the codec.

Re:Many people missing the point: HTML5, VOIP, etc (5, Informative)

jensend (71114) | about a year and a half ago | (#41306991)

No. You're confusing transmission latency with algorithmic latency. If you're encoding music to store on an mp3 player, the format can use larger transform windows (usually MDCT) and other methods which mean the encoder looks at a larger number of samples before sending any output and the decoder has to read a larger amount of data before outputting any audio.

For codecs like mp3, AAC, etc, even if you had an infinitely fast computer and infinitely fast transmission, adding an encoder and decoder between the recording and the playback adds ~200ms of latency. That's fine for storing files on an mp3 player but totally unacceptable for real-time communication. Opus, by default, has 20ms of algorithmic latency, and it can be configured to go as low as 2.5ms.

Re:Many people missing the point: HTML5, VOIP, etc (3, Informative)

pavon (30274) | about a year and a half ago | (#41307041)

No, he is using them correctly, referring to the application, not the medium.

Music playback doesn't require low latency; it doesn't matter if there is a 500ms delay between when you press the play button and you hear the music. Because of this data is encoded in (relatively) large blocks to allow for as much compression as possible.

VoIP on the otherhand does require low latency (100ms max). Otherwise it is very difficult to carry on a conversation because otherwise if you were to speak during a silence, it may not still be silent when the signal gets to when the other person, so you constantly talk over one another. The other potential application, live interactive music, requires even lower latency for musicians to keep in sync with each other. For this reason Opus is designed to encode in small blocks of data to obtain better latency.

Codec latency, not network latency (5, Informative)

cbhacking (979169) | about a year and a half ago | (#41307137)

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.

Re:Many people missing the point: HTML5, VOIP, etc (1)

stor (146442) | about a year and a half ago | (#41306845)

> This codec will change the face of the Web.

Maybe not the whole face, but hopefully it will change the mouth :)

We already have that: FLAC (0)

fa2k (881632) | about a year and a half ago | (#41306627)

It's 2012, we have the bandwidth and storage to go to lossless. There's really no need to sample at anything above 48 kHz, and 16 bit is enough for human ears, so the required space isn't too large.

Re:We already have that: FLAC (1)

bgat (123664) | about a year and a half ago | (#41306697)

It's 2012, we have the bandwidth and storage to go to lossless.

Not in wireless spectrum, especially if you are not the only radio. Far from it, actually.

Re:We already have that: FLAC (0)

Anonymous Coward | about a year and a half ago | (#41306993)

About the only two areas OPUS doesn't compete according to developer Jean-Marc Valin are lossless (where FLAC is an open format) and ultra-low bitrate, where codec2 is an open format that is amazingly good at 2.4 kbps or 1.4 kbps, and has been used for one or two ham radio links already! Codec2 isn't worthwhile online, as the packet overhead is about 8kbps.

Re:We already have that: FLAC (1)

Desler (1608317) | about a year and a half ago | (#41306725)

You realize this is for low-latency, real-time applications, right? FLAC would be terrible in that arena.

Re:We already have that: FLAC (0)

Anonymous Coward | about a year and a half ago | (#41306729)

No, we don't yet have the bandwidth. My music collection at home is all in FLAC, but I am unable to stream it on my mobile phone without it constantly stalling to buffer (the fiber-optic connection between my home and the ISP is fine, but mobile connections just aren't there yet).

One of the targets for this codec is VoIP. You'd have to be mad to think that most of the world has the bandwidth for Skype-ing in FLAC.

Re:We already have that: FLAC (1)

fa2k (881632) | about a year and a half ago | (#41306971)

Sorry, didn't look at the graph. This looks like a great development indeed, for things like VoIP and video streaming.

Getting it right the second time! (4, Interesting)

bill_mcgonigle (4333) | about a year and a half ago | (#41306707)

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 [slashdot.org] 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!

It fills a needed niche (5, Informative)

pavon (30274) | about a year and a half ago | (#41306941)

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.

Re:Getting it right the second time! (2)

WrecklessSandwich (1000139) | about a year and a half ago | (#41307019)

  • apparently it's CPU/power efficient [slashdot.org] but that's not bragged about (and many would suspect otherwise).

My understanding was that this was a pretty big issue with OGG compared to MP3. I had one of the few MP3 players at the time (~2006 or so) that supported OGG and OGG playback drained the battery noticeably faster than MP3 playback. Here's to hoping they got that part right this time.

Re:Getting it right the second time! (5, Informative)

jmv (93421) | about a year and a half ago | (#41307125)

there is test code, but I didn't see sample code explicitly.

Well, we have code snippets for the encoder [xiph.org] and the decoder [xiph.org]. Otherwise, there's always the code for opus_demo.c and opusenc.c/opusdec.c. Let me know what you think is missing and we can try improving that.

Some indications that it's not "Fully Free" ...yet (4, Informative)

smoothnorman (1670542) | about a year and a half ago | (#41306937)

none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ [ietf.org] https://datatracker.ietf.org/ipr/1741/ [ietf.org] 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.

Re:Some indications that it's not "Fully Free" ... (1, Informative)

Anonymous Coward | about a year and a half ago | (#41307085)

Those patents are openly declared as freely licensed and open-source compatible. See http://www.opus-codec.org/license/

...and it switches modes seamlessly (1)

Anonymous Coward | about a year and a half ago | (#41306943)

http://www.opus-codec.org/

Another great feature for streaming and Real Time Comms use is that it can seamlessly switch modes, channel count, bitrates, frame sizes and turn forward error correction on or off while it's playing, without glitches and without any out-of-band signalling. So if your link quality changes due to network traffic or other conditions, you can adjust to make the best of what you have. This could also be awesome for podcasts and radio shows with various types of content - e.g. super-wideband mono speech and high quality stereo music themes, stings and clips can all be part of the same stream or .opus file.

Sounds amazing to me at 64 kbps, confirmed by hydrogenaudio double-blind public listening tests (this mode was called CELT, not OPUS at the time) and google's formal testing. No wonder it's been voted for Mandatory To Implement status in WebRTC.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...