Microsoft(and probably Apple too) pays more than what it gets from the pool, so that doesn't make sense.
And everything to do with VP8/WebM being a proprietary, non standard at the time that the world consolidated on H.264. That and the fact that H.264 had hardware support when the iPods and Zunes were taking off.
Mozilla says "Audio codecs planned: G.711 & Opus. (Although royalty/license-free, we have no plans to support iLBC, iSAC and G.722)", so as it stands Firefox and Chrome could only interop with G.711 (aka uncompressed). https://wiki.mozilla.org/Platform/Features/WebRTC
If IE, Firefox, Opera, and Chrome support it, there might be enough leverage on Apple to add it to Safari (Mac, iOS, maybe iPod), too. But without Chrome, Apple has the political cover to claim that "nobody uses it," so they can kill it.
I couldn't find any direct comparison, it looks like the IETF standardization work didn't even consider it worthwhile comparing to iSAC as it was judged outdated and "being phased out". (For example, Google participated in the tests, but they only tested against iLBC, not iSAC)
So it's likely that Opus is way better. It can certainly scale to much higher quality than iSAC can just by the format alone.
Qualitywise, Opus outperforms the state-of-the-art high-latency codec at music encoding while being a low latency music & speech codec itself. The only case where another codec outperforms Opus anywhere seems to be AMR, when encoding speech at very low bitrates (<= 6-12kbps). But AMR also has higher delay.
You can read the summary here: http://tools.ietf.org/html/draft-ietf-codec-results-01
"Opus is a hybrid codec that internally uses both, SILK and Celt.
SILK was created by Skype (now Microsoft) and its patent license includes this gem: '5.1 Skype may terminate this License Agreement and any rights granted hereunder in the event that you or any of your Affiliates (i) materially breaches any of the terms and conditions of this Agreement; or (ii) asserts any patent or patent rights against Skype, its Affiliates, or its or their successors or assigns.'
So lets assume Motorola (owned by Google) tries to (counter)sue MS over some Android stuff: Suddenly the patent grant given by Skype becomes invalid and Google might have to remove Opus from Chrome. If it's popular by that time, this is a serious competitive disadvantage.
So better not help making it popular in the first place. "
I guess they're still hurting over that? :)
And Google with their proprietary WebM.
Patent-laden format for which you have to pay multi-million royalties is "industry standard".
Fact is that at least 12 organisations have already said that WebM infringes on their patents.
Their disgraceful behaviour in blackmailing Microsoft over H.264 FRAND patents is of huge concern to anyone who cares about standards. Companies should be encouraged to get together and define industry standards with fair royalty rates. When that happens we ALL win. Clearly the ITC/EU agree.
Hopefully Google will see the error of its ways and change course.
If you want to talk about bad guys in this mess, it's the companies who ended the détente by suing their competitors. That would be Microsoft and Apple. Asking companies like Motorola, HTC and Samsung to tie their hands behind their backs while Apple and Microsoft shake them down (or try to ban their products) is lunacy.
We need patent sanity in this country. But in the mean time, companies who are attacked have every right to defend themselves by any legal means they have available.
[0] http://en.wikipedia.org/wiki/Motorola_Mobility [1] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec...
And this isn't just about Motorola and Microsoft. This is about the principle of ALL contributors to a standard licensing their patents in a fair way. Regardless of whether they are being sued or not or how 'nice' the counter party is.
Do you not understand that if Motorola gets away with this then it will set in a place a precedent for all H.264 patent holders to go after any licensees ? You may not understand the implication but the ITC/EU clearly do.
Like the fact that it was Motorola that used their patents to negotiate with Microsoft long before it was acquired by Google. Or the fact that Motorola did it only after Microsoft blackmailed Motorola, using your rhetoric, with their patent portfolio in order to destroy Android not by making better products but by patent bullying.
It was NEVER a negotiation.
I left pleased about this new standard (from an advert, any downsides?) but need some patent assurances. If Mozilla are happy will everyone be?
Notice that permission is only given for implementations that comply with the specification. (And if Skype ever infringes any of your patents, you can't sue them without losing the rights to Opus.)
Whether or not you agree with Skype's moral right to its patents, this is clearly a limitation of developers' freedom. Imagine if HTTP were covered by this kind of patent: anyone could implement a client or server, but developing a backward-incompatible extension like SPDY would be off-limits. If you were to take the license terms literally, even releasing a buggy implementation that doesn't precisely follow all of the requirements of the spec would make you liable.
SILK is a speech codec developed by Skype whereas CELT is a general purpose audio codec developed by Xiph.org. Opus can use either of them (to encode speech or e.g. music, respectively) or it can use both codecs simultaneously for high-quality speech.
I'm surprised that 192k is actually indistinguishable. I thought some humans could tell the difference there.
One of the encodings will be "uncompressed" when testing if the format in question is perceptually lossless.
Repeat that a couple hundred times with many different listeners using standardized samples and programs (doom9, an audiophile forum, does such runs every now and then), and you get a rather good idea on what's going on.
As for the 192kbps: It also depends on the algorithms used. bladeenc or 8Hz-mp3 back then created 320kbps files where you can easily hear the difference. Current lame builds at 192kbps? not so much.
But most people can't distinguish a properly encoded mp3 from the original at 192kbits and often much lower than that.
That is very different to just setting itunes to 192 and expecting 'perceptually lossless'.
In terms of simple objective measures (e.g. the masking weighed SNR, http://people.xiph.org/~greg/celt/NMR.v.c.l.png) Opus does better than Vorbis (and AAC) at high rates too. Between that and the overall better time domain performance, my _expectation_ is that Opus can become perceptually lossless at lower rates, but this is hard to validate.
Getting the lowest possible average perceptual lossless rate is also a product of the encoder having a good psymodel, and released opus encoders have pretty much no explicit psymodel at all (but still manage to be competitive). So this reduces the interest in doing a bunch of very difficulty listening tests to determine the exact perceptually-lossless points, since they'll likely go down with near term encoder improvements.
I'd imagine this would have to be at least competitive with mp3/aac/ogg at those rates.
http://www.octasic.com/en/tech/opus_audio_codec.php
In my listening opinion with very good isolated headphones: the music is very good but you can hear the drop-off of the highs in the vocal examples. It's good but not good enough for 'professional' use at the lower bitrates.
I have no idea what that is supposed to mean.
/edit: spoken too soon WAV PCM is supported by WebKit, Gecko and Presto: http://en.wikipedia.org/wiki/HTML5_Audio#.3CAudio.3E_element
Most of the results returned are against old versions of the specification, too.
p=_u[_k+1];
s=-(_i>=p);
_i-=p&s;
yj=_k;
p=_u[_k];
while(p>_i)p=_u[--_k];
_i-=p;
yj-=_k;
Thats code from the inner loop of the algebraic codebook decoder. Its operation is explained by a 117 line long comment in the source, and by a page long description of a simplified algorithm in the spec. Beyond replacing it with an alternative implementation which would naturally have nothing in common there isn't much to maintain in it (and that code itself has been proven correct through exhaustive testing as well as the partially-exhaustive unit tests for it included with the codec).
Most of the codec doesn't look like that. Though it's not all easy to read— e.g. a lot of the signal processing stuff is intermediated by macros so that it works for both fixed point and floating point. And if you don't like it then, by all means, write your own. Having more interoperable implementations would be great. Most formats don't give you a BSD licensed reference implementation.
::shrugs::