Firefox Beta 15 supports the new Opus audio format
hacks.mozilla.org
hacks.mozilla.org
The times have changed though, and the IETF is now receptive to this type of work (although it didn't happen without a political battle). Note that many of the Opus contributors are Xiph.org contributors as well.
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.
How is a codec I can download in complete source form and use in any way I like without licensing anything or answering to anybody "proprietary"?
The fact that we live in a world full of patent trolls that will sue you for tying your shoelaces doesn't make every codebase without explicit corporate patent indemnity "proprietary".
The WebM trademarks and copyright are owned by Google.
Yes you have a license to use WebM as it is today. But Google can make the next version closed source and you wouldn't be able to do anything about it. And of course companies are going to use Google's 'official' WebM regardless if it is open or closed source leaving you screwed.
By your definition anything not in the public domain is proprietary.
As far as I am aware of, any user of WebM are NOT restricted from modification, further distribution, or reverse engineering. The beauty of the current licencing is that it can't be revoked; it is already free. Google can develop future versions and lock it down (suicidal move, though), but as it is the community has its hands on it.
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.
Google owns WebM and unilaterally makes the decisions about the direction of the format. H.264 is a standard and driven by a standards committee and process comprising numerous companies.
Also, war is peace, freedom is slavery, and innocence is strength!
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
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.
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.
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.
I guess they're still hurting over that? :)
"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 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.
> Notice that permission is only given for implementations that comply with the specification.
That's typical - otherwise, you could implement some almost arbitrary protocol but say it was this one (and use a small amount of it) and claim that you were shielded from Skype's patents. The patent license is just for this particular codec.
Of course there are issues with this, it's been debated a lot regarding the Java and C# licenses, which also have similar clauses for similar reasons. The motivation for them is reasonable, but the details can be tricky.
> (And if Skype ever infringes any of your patents, you can't sue them without losing the rights to Opus.)
Personally I think that's fine. If you want to engage in a full-on patent war, you should not benefit from a patent license like this.
> 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.
If a single bug makes you liable, obviously it is unfair, etc, but that's exactly where the details of the license come into play - I am not a lawyer, so I have no idea if the terms here are reasonable or not.
No, that's what standard bodies are for. No need for stupid patent licenses.
Besides, this is exactly why this isn't free.
Could I make a format based on Opus, but not conforming to the spec? Maybe because I had an idea for better algorithms in some parts? No. I cannot take the parts of Opus which fall under Skype/Microsofts patents and use them in derivatives. This means that both the implementation as well as the standard are free and open on paper only. In reality, I am denied freedom number 3 - the right to distribute modified implementations.
Take note that you could just solve this with a trademark on Opus (which probably already exists). Many large FLOSS projects do that. Firefox, for example - derivatives are not allowed to call themselves "Firefox" (which I think is one of the very few valid uses of trademarks).
If Skype/Microsoft would be actually interested in a free and open standard, they would have pledged to let go of these patents. I don't know if you can just say "this patent is now invalid", but if not, they could hand them over to the standard body, which could then assure that everybody is allowed to use these patents until they expire.
>Personally I think that's fine. If you want to engage in a full-on patent war, you should not benefit from a patent license like this.
I find it quite funny that people already implictly assume that if someone starts a patent infringement lawsuit, they are in for patent war. Please tell me again why we haven't got rid of patents yet?
Speaking as one of the authors of the spec here, this is very much not the intention. I personally believe a patent license should never be used to enforce standards compliance, and that's not the purpose of that term. Keep in mind, I don't think anyone involved in this standard wants to go around suing people, particularly those interested in implementing and deploying it! In addition to being a gigantic waste of time and money, it would kill the standard dead.
But we specifically included a conformance test to make it easy to know if you met the legal requirements, so you didn't have to trust us. At the request of the working group, this test was made so lax that we worried you could start deleting random lines of code (as an "optimization") and still manage to pass it (to combat this the test also displays a "quality" parameter which drops long before you get to the failure point, so implementors can start marketing that number if their competitors try this tactic, instead of being stuck in a race to the bottom).
In this case though, Microsoft only has patents on part of the algorithm, so it is theoretically possible that other parts of the algorithm are covered by other patents.
The problem though is that anything complex like a video or audio codec can constitute many "inventions" from the USPTO's point of view. H.264 has many patents on it, for example. Again, this is one of the big problems with the current patent system.
So in practical terms you can never use a codec with the knowledge that no one else has patents on it.
Read up on the rationale behind the CC0 license for more information:
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'.
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.
Opus outperforms that greatly, but it's not going to outperform MPEG1 Layer 2 at 256kbps while only outputting 64kbps itself. (Will likely need >= 96kbps for that).
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.
/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::