Luckily it's going to be W3C standard, and Apple and MS won't be able to use their lame excuses to avoid implementing it in their browsers, like they did for Vorbis, VP8 and etc.
Potentially yes. But Microsoft and Apple not supporting VP8 & WebM probably has more to do with these companies being part of MPEG LA (a firm which sell licenses for H.264 related patents).
That seems like a leap. Ogg codecs were always questionable to me because they are owned by xiph.org, rather than some other more widely accepted standards body.
We tried to get IETF and W3C interested. They barely talked to us. The most we could do was a Vorbis over RTP draft that I wrote. The next best option was to incorporate as a 501c3 and run our own standards body, similar to the XSF in the XMPP world.
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.
>But Microsoft and Apple not supporting VP8 & WebM probably has more to do with these companies being part of MPEG LA (a firm which sell licenses for H.264 related patents).
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.
You keep using this word "proprietary". I don't think it means what you think it means.
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".
Proprietary: "something that is used, produced, or marketed under exclusive legal right of the inventor or maker."
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.
Wow you're really reaching here now, aren't you? The bitstream format and software are licensed under a Creative Commons Attribution License and the BSD license, respectively.
By your definition anything not in the public domain is proprietary.
Let's get another definition. This one is from wikipedia: Proprietary software is computer software licensed under exclusive legal right of the copyright holder. The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering.
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.
So to be clear, you admit that WebM isn't proprietary, but future versions could be? That's true of every open source project on the planet, that's how copyright law works.
Because it'll show that they aren't supportive of Web standards and they'll look like complete fools - bad PR for them. That's why they were sabotaging any attempts to make other open codecs (like VP8) an official standard for HTML5 video. It's much harder for them to explain why they oppose official Web standards, than just to say they aren't supporting one of the optional codecs.
Where is Google in all this? They must surely be aware of all such IETF projects. I can understand why Apple wasn't mentioned (Apple Island is a world unto itself to the maximum extent possible), but Google has usually pursued the opposite strategy. This seems like the sort of thing they would get behind unless there is some issue I'm unaware of, and it seems as though Mozilla would mention Google in this infomercial if they were backing it.
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
Very interesting. That Google Group you link to is very busy with responses to almost all threads, but the one you link to, the May 9 offer to add Opus to Chrome, was met by the sound of crickets.
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.
Skype used the SILK part of Opus to replace iSAC quite a while ago. (SILK is in fact their second iteration of their own codec to improve upon/replace 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.
Opus, A lot better, it is a rather strange beast that it nearly manage to outperform in every category. With a bit more tuning work for a year or two it could properly be on the same level with AAC @ 256Kbps.
Well, I suspect they talked to their legal department which _might_ have reasoned like this (IANAL, btw):
"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. "
Skype/MS should just make it fully open source then, for the betterment of the web, instead of using it for potential silly legal fights in the future.
Google apparently participated in the listening tests and concluded Opus outperformed the GIPS codecs they had just bought for 68 million USD, sometimes by wide margins.
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.
The code may be open source but the format/spec is 100% controlled by Google. Forking the code won't help you change the direction of format development. If anyone besides Google wants to make changes, they'd have to fork the entire spec under a different standards body.
As you would with any standard. If h.264 were open source you couldn't fork it and have it work with existing h.264 devices. It would be a new standard.
Also we should point out that Google should NEVER be trusted.
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.
Seriously? Google has owned Motorola Mobility for fewer than two months[0]. And in any case, though it seldom matters to people insistent on seeing the Android manufacturers in a bad light, Microsoft started this war by demanding licensing fees for ridiculous patents, like this one, for "Generating meeting requests and group scheduling from a mobile device"[1].
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.
I fail to see how it matters how long Google has owned Motorola. They are the ones making the decisions.
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.
Google did not own Motorola Mobility when the FRAND stuff went down (in February). If you can't see how that's relevant then I guess you probably can't see much at all.
Propaganda is always easier if you fail to mention all the facts.
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.
Ogg is a container format. The Opus support in Firefox is Opus inside the Ogg container. You probably mean "why isn't Vorbis good enough". Even the article has this error when it says that Opus compression is better than Ogg. They mean Vorbis there presumably.
Unfortunately, according to Wikipedia, Skype holds software patents on parts of
the algorithm. Even though they said they'd make them avaiable royalty-free, this
still means it isn't completely free.
In what way is using a technology not free, if you are given a royalty-free license to use the patents on it? (Honest question, I don't know what you mean here.)
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.
>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.
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?
>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.
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 some ways, a perpetual unrestricted license is better than an unpatented algorithm. The big excuse for not adopting webm was "uncertainty" about the patent situation. If skype has the patents and is giving free licenses, there isn't any uncertainty here, you know that microsoft has no basis to ever sue.
This is true and is one reason that free things these days are given "licenses" instead of simply being declared by their makers to be in the public domain. The public domain isn't what it used to be.
It's impossible to declare a work under the public domain in the USA. A creative work reaches the public domain only when its copyright expires, or if it's a government work.
Read up on the rationale behind the CC0 license for more information:
To some (significant) degree, but you never know that no one else has patents on a technology. That's exactly what is so messed up with software patents.
On any specific technology, you absolutely can know that no one else has patents on it. That is the responsibility of the patent office: to grant exclusive rights to an 'invention'. you cannot be held liable for infringement of anything you have a license for.
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.
It's rare, but I remember reading that USPTO has mistakenly issued conflicting patents. Legally, any publication is enough to bar others' patents, they're just not good at finding anything in the software literature, so having your own patent sort of rubs examiners' noses in it.
> On any specific technology, you absolutely can know that no one else has patents on it. That is the responsibility of the patent office: to grant exclusive rights to an 'invention'.
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.
And in certain situations it's better not to know, because knowingly infringing patents can result in significantly higher monetary penalties than unknowingly infringing them.
I vehemently disagree. This is supposed to become an open standard. Open
standards must, in my opinion, be completely free. No compromises. No
exceptions. No footnotes. No patent bullshit.
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.
My somewhat educated take on that is that 'perceptually lossless' refers to quality at which the source cannot be reliably picked from the source/encode in any sort of test that would pass as scientific, possibly outside of a few very rare edge cases (sound samples, not people). This happens at lower bitrates than many people might imagine, IIRC v2 lame (~192kbps) has not been reliably identified, nor vorbis v6 (~160kbps). So their claim of 'perceptually lossless' at 256kbps is neither surprising or impressive. (it may be competitive/better at those high bitrates and they are just being conservative with the claims).
Usually it's double blinded ABX testing: A computer program gives you: Encoding A, encoding B, unknown encoding A or B. You have to choose if X is A, or X is B.
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.
Worth noting it is 'v2', which is a specific setting with a specific encoder (lame) that creates a variable bitrate file which averages around 192kbps.
That is very different to just setting itunes to 192 and expecting 'perceptually lossless'.
They mention 256kbps in regards to that, at which point all of vorbis, aac and mp3 (lame) are 'perceptually lossless', so it wouldn't be much new. While it is hard to tell (because tests at higher bitrates don't really work out/ produce winners), it seems that any sonic advantage held is at the lower bitrate end.
Measuring the point where something becomes perceptually lossless is quite difficult because, by definition, you're measuring at the bounds of perceptibility.
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.
Lossy audio compression over about 160kbits is a boring subject these days because for the vast majority of users and samples it's more than good enough.
I'd imagine this would have to be at least competitive with mp3/aac/ogg at those rates.
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.
Audio compression is generally not used for production audio (film sound, television etc), but on occasion they'll use MPEG2 for remote transmission. This is a lossy codec but sounds better than the example provided, albeit at 128kbps so I'd need to hear the Opus codec at 128kbps to compare.
MPEG2 isn't an audio codec, it's a suite of standards. But based on my experience writing hardware encoders for this use case, you're talking about MPEG1 Layer 2 audio.
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).
I already posted tests results elsewhere in this topic. It outperforms it at low bitrates. I suspect also at higher ones but once both codecs get imperceptible for most listeners (which is the case for AAC and Opus >128kbps) it's very hard to get statistically significant results.
I'm curious how that works. It decodes the FLAC in JavaScript, but it still has to expose it in some format understood by the browser. To my limited knowledge there's no lossless encoding scheme supported by browsers, not even WAV PCM.
The IETF datatracker link is pretty useless. Pretty much anyone can make any claim they want there and there is no way to remove it. Its just a statement collector, not a review.
Most of the results returned are against old versions of the specification, too.
Why not. They might propose using VP8 combined with Opus (not sure how it'll be called) for video. The problem however is in the same lack of support, since VP8 is still boycotted by Apple and MS so far.
I understand they were trying to finalize the spec and weren't worried too much about the individual encoder decisions, but check out some of the code at the bottom of this convo, it's scary http://pbox.ca/16cbg
What maintenance are you looking to perform on it?
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.
