Comments on Cisco, Mozilla, and H.264
Oct. 30th, 2013 08:35 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xiphmontPlease note: This is not a statement on behalf of Xiph.Org or Mozilla. I speak here for myself, my team, and other developers who share my views on an open web.
If you haven't seen today's announcements from Cisco and Mozilla regarding H.264, you'll want to read them before continuing.
Let's state the obvious with respect to VP8 vs H.264: We lost, and we're admitting defeat. Cisco is providing a path for orderly retreat that leaves supporters of an open web in a strong enough position to face the next battle, so we're taking it.
By endorsing Cisco's plan, there's no getting around the fact that we've caved on our principles. That said, principles can't replace being in a practical position to make a difference in the future. With Cisco making H.264 available at no cost, holding out against H.264 in WebRTC makes even less sense than holding out after Google shipped H.264 in the video tag. At least under these terms, H.264 will be available at no cost to Mozilla and to any other piece of software that uses the downloadable plugin.
Cisco's license hack is obvious enough if you have the money: There's a yearly cap on total payments for any given licensed H.264 product. This year the cap is $6.5M. Any company that pays the cap each year can distribute as many copies as they want. There are still terms and restrictions on how the distribution gets done, but Cisco will be handling that (and only Cisco will be allowed to build and distribute these copies without a separate license).
Once you or your applications download the prebuilt codec blob from Cisco, you're allowed to use that specific blob for anything you want so long as you don't modify it or give it to anyone else. H.264 codecs for everyone! Cisco has committed to these blobs being available for just about every platform and architecture you can think of. "IBM S/360? Yes, please!"
This arrangement has obvious short-term benefits. Open source projects get licensed (if partial and restricted) access to H.264, and users don't feel like they're being held hostage in the ongoing battle between the open web and closed codecs. Firefox and other projects can install H.264 support (via Cisco), which is a big deal.
That said, today's arrangement is at best a stopgap, and it doesn't change much on the ground. How many people don't already have H.264 codecs on their machines, legit or otherwise? Enthusiasts and professionals alike have long paid little attention to licensing. Even most businesses today don't know and don't care if the codecs they use are properly licensed[1]. The entire codec market has been operating under a kind of 'Don't Ask, Don't Tell' policy for the past 15 years and I doubt the MPEG LA minds. It's helped H.264 become ubiquitous, and the LA can still enforce the brass tacks of the license when it's to their competitive advantage (or rather, anti-competitive advantage; they're a legally protected monopoly after all).
The mere presence of a negotiated license divides the Web into camps of differing privilege. Today's agreement is actually a good example; x264 (and every other open source implementation of an encumbered codec) are cut out. They're not included in this agreement, and there's no way they could be. As it is, giving away just this single, officially-blessed H.264 blob is going to cost Cisco $65M over the next decade[2]. Is it any wonder video is struggling to become a first-class feature of the Web? Licensing caused this problem, and more licensing is not a solution.
The giveaway also solves nothing long-term. H.264 is already considered 'on the way out' by MPEG, and today's announcement doesn't address any licensing issues surrounding the next generation of video codecs. We've merely kicked the can down the road and set a dangerous precedent for next time around. And there will be a next time around.
So, we're focusing on being ready.
Fully free and open codecs are in a better position today than before Google opened VP8 in 2010. Last year we completed standardization of Opus, our popular state-of-the-art audio codec (which also happens to be the best audio codec in the world at the moment). Now, Xiph.Org and Mozilla are building Daala, a next-generation solution for video.
Like Opus, Daala is a novel approach to codec design. It aims not to be competitive, but to win outright. Also like Opus, it will carry no royalties and no usage restrictions; anyone will be permitted to use the Daala codec for anything without securing a license, just like the Web itself and every other core technology on the Internet.
That's a real solution that can make everyone happy.
I can't resist a little codec fantasy football.
MPEG HEVC licensing isn't set yet. It will be interesting to watch the negotiations if Cisco's H.264 giveaway plan is wildly successful. In the future, could nearly every legal copy of HEVC come as a binary blob from one Internet source under one cap? I doubt that possibility is something the MPEG LA has considered, and they may consider it now that someone is actually trying to pull it off with H.264. Perhaps in five years, even cameras and televisions will download a software codec to avoid paying monopoly rents. Sillier things have happened given sufficient profit motive.
Or maybe they'll build in a free, legally uncomplicated copy of Daala instead. Dare to dream.
—Monty Montgomery <monty@xiph.org> and others
October 30, 2013
[1] According to the MPEG LA there are only 1276
H.264 licensees (of all kinds) worldwide.
Source: http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
[2] Cisco's cap liability is $65M over ten years only if
the cap amount doesn't change. Historically, the cap has increased
every few years, depending on the end-use license. For non-commercial
content delivery products, the cap was $3.5M for 2006-7, $4.25M for
2008-9, $5M for 2010 and is currently $6.5M for 2011-15.
Source: http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf
no subject
Date: 2013-10-30 03:46 pm (UTC)Opus's place in WebRTC is not in jeopardy. For one thing, it significantly outperforms its competition, and there's no substantial body of content for which backward compatibility is more important than technical or licensing considerations. We've also apparently done a good job answering our IP critics.
no subject
Date: 2013-10-30 04:14 pm (UTC)This is about the WebRTC standard
Date: 2013-10-30 04:55 pm (UTC)This is about the WebRTC standard, which is a communications standard. Basically, realtime audio and video calls in HTML5. The standard that is being discussed has nothing to do with web video like Youtube, which is the legacy mentioned earlier.
A side benefit of WebRTC will the assumption that your browser can support Opus, meaning we can have a better audio codec as standard for new video, but currently AAC will remain the standard for previous videos. By the time Daala comes around, hopefully Opus will be the standard.
(Opus is interesting in that it changes its compression characteristics to optimize for low bandwidth high quality. This is the standard that many LTE phones that have High Quality audio are using to conserve bandwidth in the crowded cellular space where conserving bandwidth is their highest priority.
Re: This is about the WebRTC standard
Date: 2013-10-31 03:19 am (UTC)Re: This is about the WebRTC standard
Date: 2013-10-31 05:11 am (UTC)If this was a purely technical decision, you'd be absolutely right.
There are numerous players who Will Not implement VP8/WebRTC whether IETF says it's MTI or not. "Why?" is subject I could write about full time for the next year. Of course, the IETF is highly unlikely to declare anything MTI without consensus.
> My point is that without MPEG audio neither of those points hold.
I assume you mean AAC. In WebRTC, audio transcoding (or coding in software) isn't a backbreaker. Video would be. For the video tag, Mozilla fully intends to find a way to ship AAC.
Re: This is about the WebRTC standard
Date: 2013-10-31 08:43 pm (UTC)Also, if some players (Apple and co?) would just ignore IETF if they are to mandate VPx, why would they change their mind in case of Opus and Daala let's say? Because of no Google shadow behind them and less patent risks? My perception was, that those who tried to sabotage VPx did that because of their own interests, not because they were scared of risks.
Re: This is about the WebRTC standard
Date: 2013-11-06 10:54 pm (UTC)Occam's razor would suggest they see potential profit in WebRTC, and interoperability is essential to WebRTC succeeding. I do believe that Cisco see themselves as being the good guys here, and taking one for the team (in the interests of profit down the line). Cisco is not really concerned with Free or Open Source beyond misusing those terms in their press releases. But that's not to say I think they're trying to be sneaky.
>Also, if some players (Apple and co?) would just ignore IETF if they are to mandate VPx, why would they change their mind in case of Opus and Daala let's say?
That's a good question, and a real concern. But we can see that, eg, Apple has not engaged in any obstructionism or FUD regarding Opus as far as I know. Opus also has the advantage of being technically compelling in a way no competing codec is, so much so that it's disrupted a parallel MPEG effort (USAC). We also developed Opus in the open and answered Opus's IP critics promptly, forcefully, and apparently successfully. There's no significant IP-based pushback against Opus, and in general the press opinion of Opus is full of warm fuzzies.
We'll be using the same strategy with Daala.
And where did VP8/9 go wrong? Several commentors in the mainstream press noticed that I mentioned VP8 in my post only in passing, and VP9 not at all. Exactly why could fill a several page blog post, but the short version is: The IPR story (not the reality, the story) around VP8/9 is... pretty bad.
On2/Google took a strategy that was risky where the press was concerned. VP8/9 are not copies of the MPEG codecs, but they have identical basic architecture. This backfired in the press immediately when Jason Garrett-Glaser published his infamous 'VP8 is a copy and must be infringing' blog post and Google never answered it.
Google's not publicly addressed any of the ongoing assertions of infringement in any convincing way. Instead, their strategy was to wait for the lawsuits and win decisively in court. As a result, the MPEG side ('VP8/9 are dirty copycat infringers') has ruled the story from the beginning. Google is finally winning the first court cases years later, but that's hardly bolstering their argument now-- now the public thinks VP8 is both infringing _and_ a lawsuit magnet, and why would they expect VP9 to turn out differently?
And really, that's only the half of it. Just about everything that could go wrong with Google's press story around VP8/9 has gone wrong. They took a risky path and rolled several critfails right out of the gate. At this point even mentioning VP8 or VP9 in our own press seems like a mistake, and that's too bad. The VP codecs didn't deserve this outcome.
no subject
Date: 2013-10-30 06:06 pm (UTC)H.264 can work along with Opus just fine, and not with AAC only. And Opus is already a mandatory part of the WebRTC spec, so any compliant implementation will have to support Opus.
no subject
Date: 2013-11-01 01:23 am (UTC)no subject
Date: 2013-11-06 12:35 pm (UTC)It also sets a precedent and you can't trust the patent holders to act in anything other than their own cartel's interest (the last time I checked H.264 "essential" patents were due to last an extra year than the previous time I looked) so it seems like something Mozilla and Xiph might be ideally placed to sort out (perhaps in conjunction with FSF/Debian/Google and other interested parties). Obviously Xiph has Vorbis and Opus which are both technically superior, but the installed base of MP3 is massive.
no subject
Date: 2013-11-06 11:00 pm (UTC)(OTOH, mp4 aka AAC is not far and away more compelling than mp3. Maybe people will end up moving to Opus instead :-)