DCAWD.com

Microsoft Client Platform team member Tim Sneath jabbed Google for its decision to drop H.264 support in HTML5 for Chrome in favor of WebM. He compared it to a country deciding to drop English as a language in favor of artificial languages like Esperanto and Klingon. The remarks pointed out the irony of claiming to promote openness and choice by artificially removing the most practical, popular option.

"Though English plays an important role in speech today, as our goal is to enable open innovation, its further use as a form of communication in this country will be prohibited and our resources directed towards languages that are untainted by real-world usage," he joked.

He also underscored the gap between actual usage and Google's claims that WebM was well adopted, pointing out that Esperanto had broad use by "as many as 10,000 speakers."

The criticism echoes that of many commenters following Google's abrupt change in policy. Most mainstream accessible HD video both online and off today is encoded in H.264 and would need to be either transcoded or put into a Flash container to be viewable in Chrome. Some developers and video editors have said they plan to abandon Chrome as an explicit target since they would have to support at least two and possibly three video implementations to get Chrome to work.

Sabre wrote:wa' jaj loD tlhIngan Hol DIchDaq taH Hol vaD qo'

H.264 Trouble
H.264 is problematic and bad for the web for many reasons I’ve mentioned here before as well as great posts by roc and shaver. I’ll leave it at that rather than rehash.
There was buzz a while back about H.264 being “free” (quotes intentional), but it’s not really “free” if you read the fine print. As Peter Csathy of Sorenson Media notes:
But, you say, MPEG LA recently announced that it will no longer charge royalties for the use of H.264. Yes, it’s true – MPEG LA recently bowed to mounting pressure from, and press surrounding, WebM and announced something that kind of sounds that way. But, I caution you to read the not-too-fine print. H.264 is royalty-free only in one limited case – for Internet video that is delivered free to end users. Read again: for (1) Internet delivery that is (2) delivered free to end users. In the words of MPEG LA’s own press release, “Products and services other than [those] continue to be royalty-bearing.”
That’s hardly “free”. That’s just one potential use case that’s now royalty exempt. The reason they are doing that is presumably if they can get H.264 adoption high enough, all the other cases will be paying and therefore subsidizing this one case.
WebM is licensed a little different: Patent wise, it’s irrevocably royalty free. License is about as liberal as you can get.
There’s no proprietary html, css, or images (GIF was, now it’s dead) used across the web. Why should video be any different? The key to success and growth has always been an open platform that’s low cost and encourages innovation.

Sabre wrote:
As I said above, I wish they had kept support for H.264 for legacy reasons, but I totally understand why they decided to drop it in favor of WebM.

Google has recently announced their intention to remove the H.264 video codec from its Chrome browser. This decision has been smeared as an evil campaign for controlling video on the web, akin to not-invented-here syndrome. It’s also been lauded as the push that the web needs to remain open and free. Mostly, it’s been marked as inconsistent, due to the bundling of Adobe’s proprietary Flash player.

Richard Stallman doesn’t like the term Open Source because it fails to embody the true meaning of “free software”, and the one thing that’s worse is the word “open”. This debate can’t simply be labeled as one for or against openness (even ignoring the technical details).

H.264 is an open standard. It was developed by a committee, standardized, reviewed by many engineers and developers for multiple companies and has been standardized for use with a multitude of containers and devices. However, H.264 is not royalty free. Software patents in many countries restrict the distribution of software that utilizes the codec to those who pay the MPEG-LA.

VP8 is not a standard. It was developed secretly by a single company, and until recently, had only a single working implementation. The public wasn’t open to collaboration on the specification until the bitstream spec was frozen, including the bugs that existed within. Now, the source code and reference implementation are available under liberal licenses, and all the related patents are irrevocably royalty-free.

Adobe Flash, while not synonymous with a video codec (unless you mean .flv flash videos, which are either VP6 or Sorenson Spark), is going here anyway because everyone feels like comparing it. Flash’s SWF format is not standard, but it is open. There are a few implementations (Swfdec, Gnash, GameSWF, Gordon, etc), but none of them are as complete as the official proprietary implementation. There’s a bitstream specification that anyone can read to create an independent implementation of the player. Implementing and using the Flash player is still royalty-free (Since the Flash VM can decode H.264, obviously that part, not controlled by Adobe still has royalties), anyone can make software that can export SWF animations without paying Adobe.

Code: Select all

Implementation vs. Distribution

Or: How Bundling Flash doesn’t violate the Novikov self-consistency principle

Name	  Standardization	  Implementation	Distribution	Dev History
Theora	Standardized?	    Open Source	   Royalty Free	Mostly Open
VP8	   Not Standardized	 Open Source	   Royalty Free   Mixed
H.264	 Standardized	     Open Source	   Royalties	   Open
Flash*	Not Standardized	 Proprietary	   Royalty Free	Proprietary

...

Often, the argument against VP8 is that it’s inferior to the H.264 codec, and to me, this seems like the most ideologically valid concern. But in a lot of cases, it stems from a misunderstanding of how H.264 works. H.264 is not a single video codec (not even to mention multimedia container formats), but rather has several Profiles that work on different devices and implementations. Rarely are videos encoded only in MPEG-4/AVC H.264 Extended Profile at 1080p and 60fps. Go on the Apple store and you’ll see that every iPod device you can find (including the iPhone), includes what video codecs are supported. And it doesn’t just say H.264, but rather, something much more wordy like

Video formats supported: H.264 video up to 720p, 30 frames per second, Main Profile level 3.1 with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

For the insanely great iPhone 4. Google is meaner and doesn’t make the information about profile support on the Nexus S quite as accessible (though it’s not the only reason I’m an iPhone user), but it should be safe to assume it’s something along the lines of what the iPhone 4 supports. The iPod Classic has a nice, even longer string, that represents even less support for H.264:

H.264 video, up to 1.5 Mbps, 640 by 480 pixels, 30 frames per second, Low-Complexity version of the H.264 Baseline Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; H.264 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Baseline Profile up to Level 3.0 with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats;

This is because very few devices can actually utilize all the great features that H.264 defines. Wikipedia has a nice pretty chart. So the point of all of this is to say, even though VP8 is inferior to H.264 from a purely technical standpoint, you probably can’t just use the Main or Extended profiles to support all the devices that “support H.264″. Does this invalidate the inferiority argument? Nope. Dark Shikari said “I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264″. But the large number of devices that support H.264 might actually only support the baseline profiles.

...

VP8 is a bit worse than H.264, and had it been a patent encumbered video format, there would be almost no reason to prefer it over AVC. The <video> part of the HTML5 specification states:

It would be helpful for interoperability if all browsers could support the same codecs. However, there are no known codecs that satisfy all the current players: we need a codec that is known to not require per-unit or per-distributor licensing, that is compatible with the open source development model, that is of sufficient quality as to be usable, and that is not an additional submarine patent risk for large companies. This is an ongoing issue and this section will be updated once more information is available

The only major codecs that are royalty free are Theora and VP8, and the former probably isn’t of sufficient quality. Both of them come with patent risks (or at least that’s what MPEG-LA wants people to believe), leaving a set of zero acceptable codecs. For this to work at all, something needs to be compromised.

H.264 defines a baseline profile that all decoders could be reasonably expected to handle. Such a profile exists so that the video can be viewed, albeit with inferior compression on a variety of devices and platforms with limited computational ability. The internet was built on interoperability, and HTML5 needs an equivalent “baseline codec” for the web. Something that compresses video at sufficient, though not bleeding-edge quality. Something that can be implemented and distributed openly on all platforms.

Hello from the frigid city of Oulu, in the far north of Finland. Our WebM hardware development team, formerly part of On2 Technologies, is now up-to-speed and working hard on a number of video efforts for WebM.
VP8 (the video codec used in WebM) hardware decoder IP is available from Google for semiconductor companies who want to support high-quality WebM playback in their chipsets.
The Oulu team will release the first VP8 video hardware encoder IP in the first quarter of 2011. We have the IP running in an FPGA environment, and rigorous testing is underway. Once all features have been tested and implemented, the encoder will be launched as well.

WebM video hardware IPs are implemented and delivered as RTL (VHDL/Verilog) source code, which is a register-level hardware description language for creating digital circuit designs. The code is based on the Hantro brand video IP from On2, which has been successfully deployed by numerous chipset companies around the world. Our designs support VP8 up to 1080p resolution and can run 30 or 60fps, depending on the foundry process and hardware clock frequency.

The WebM/VP8 hardware decoder implementation has already been licensed to over twenty partners and is proven in silicon. We expect the first commercial chips to integrate our VP8 decoder IP to be available in the first quarter of 2011. For example, Chinese semiconductor maker Rockchip last week demonstrated full WebM hardware playback on their new RK29xx series processor at CES in Las Vegas (video below).

The WebM video hardware IP designs support encoding and decoding WebM/VP8 video up to 1080p resolution. Implemented as RTL source code (VHDL or Verilog), both WebM IP designs are available under a no-cost license. Please complete the request formto find out more.

complacent wrote:it means they're worried about people not being able to view content.

MPEG LA's AVC/H.264 Patent Portfolio License provides access to essential patent rights for the AVC/H.264 (MPEG-4 Part 10) digital video coding standard used in set-top boxes, media player and other personal computer software, mobile devices including telephones and mobile television receivers, Blu-ray DiscTM players and recorders, Blu-ray video optical discs, game machines, personal media player devices, still and video cameras, subscription and pay-per view or title video services, free broadcast television services and other products. To align with the real-world flow of AVC/H.264 commerce, reasonable royalties are apportioned throughout the AVC/H.264 value chain. The License employs annual limitations to provide cost predictability, threshold levels below which certain royalties will not be charged in order to encourage early-stage adopters and minimize the impact on lower volume users or demo products, and certain licensing options that require no royalty reports.

MPEG LA Announces Call for Patents Essential to VP8 Video Codec
MPEG LA Offers to Facilitate Development of a Joint License to Provide Coverage Under Essential Patents
(DENVER, CO, US – 10 February 2011) – MPEG LA, LLC, world leader in alternative one-stop patent licenses, announces a call for patents essential to the VP8 video codec specification used to deliver video images. The VP8 video codec is defined by the WebM Project at http://www.webmproject.org.

In order to participate in the creation of, and determine licensing terms for, a joint VP8 patent license, any party that believes it has patents that are essential to the VP8 video codec specification is invited to submit them for a determination of their essentiality by MPEG LA’s patent evaluators. At least one essential patent is necessary to participate in the process, and initial submissions should be made by March 18, 2011. Although only issued patents will be included in the license, in order to participate in the license development process, patent applications with claims that their owners believe are essential to the specification and likely to issue in a patent also may be submitted. Further information, along with terms and procedures governing patent submissions, can be found at http://www.mpegla.com/main/pid/vp8/default.aspx.

VP8 Specifiation

The VP8 Specification is described in the following document, including any and all amendments: VP8 Data Format and Decoding Guide, WebM Project, Revised: February 4, 2011 (http://www.webmproject.org/media/pdf/vp8-bitstream.pdf).

Source

Additional IP Rights Grant (Patents)

"This implementation" means the copyrightable works distributed by Google as part of the WebM Project.

Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8. This grant does not include claims that would be infringed only as a consequence of further modification of this implementation. If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.

Software License

Copyright (c) 2010, Google Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Neither the name of Google nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Sabre wrote:I've been meaning to respond to you comments for awhile, but wanted to check a couple of things first Looks like WebM is licensed under a BSD license (ya!). Here is the part that is interesting:

Source

Additional IP Rights Grant (Patents)

"This implementation" means the copyrightable works distributed by Google as part of the WebM Project.

Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8. This grant does not include claims that would be infringed only as a consequence of further modification of this implementation. If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.

While they will not protect you if someone else comes after you for legal action for anything else, the license protects you from being sued for anything related to the VP8 codec.

Sabre wrote:M$ is willing to write a plugin for Chrome because they have a monetary stake in H.264 (they make money off the licensing). So of course they want people to use it. Same for Apple. Google does not make any money off of the licensing of VP8. They cannot make money off of patent lawsuits from it (like M$, Apple and MPEG-LA do).

Apple Inc.

Cisco Systems Canada IP Holdings Company

DAEWOO Electronics Corporation

Dolby Laboratories Licensing Corporation

Electronics and Telecommunications Research Institute

France Télécom, société anonyme*

Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.

Fujitsu Limited

Hewlett-Packard Company

Hitachi, Ltd.

Koninklijke Philips Electronics N.V.

LG Electronics Inc.

Microsoft Corporation

Mitsubishi Electric Corporation

NTT DOCOMO, INC.

Nippon Telegraph and Telephone Corporation

Panasonic Corporation

Polycom, Inc.

Robert Bosch GmbH*

Samsung Electronics Co., Ltd.

Sedna Patent Services, LLC

Sharp Corporation

Siemens AG

Sony Corporation

Tandberg Telecom AS

Telefonaktiebolaget LM Ericsson

The Trustees of Columbia University in the City of New York

Toshiba Corporation

Victor Company of Japan, Limited

How much do software makers and content providers have to pay the patent pool holders (via MPEG LA)? I reviewed the Summary of AVC License Terms, which sets out the royalties to be paid for different uses of the technology. (You can find all the MPEG LA documents here.) A perusal of the rates in that agreement indicates that the fees are not outrageous at this time. For example, here’s a breakdown of the royalties that must be paid if you use H.264 as part of a subscription-based video service. The amounts are charged annually and are based on the number of subscribers:

* 100,000 or fewer subscribers = no royalty
* 100,001 to 250,000 subscribers = $25,000
* 250,001 to 500,000 subscribers = $50,000
* 500,001 to 1,000,000 subscribers = $75,000
* greater than 1,000,000 subscribers = $100,000

Do the math. If you have 350,000 subscribers, your annual royalty cost per subscriber is a little over 14 cents, or 1.2 cents per month. Not exactly exorbitant.

What if you’re a software developer? Assuming you’re building a “branded encoder and decoder products sold both to end users and on an OEM basis for incorporation into personal computers but not part of an operating system,” here’s the fee schedule:

* 0 - 100,000 units per year = no royalty
* US $0.20 per unit after first 100,000 units each year
* above 5 million units per year, royalty = US $0.10 per unit.

The maximum annual royalty (“cap”) for an enterprise as of 2010 is $5 million per year. Update: For 2011-2015, the maximum annual royalty has increased to $6.5 million.

If you’re distributing fewer than 100,000 copies, you pay nothing. Beyond that, you pay up to 20 cents per copy.

The threat of future lawsuits has helped persuade some companies to forsake VP8. Apple's chief executive, Steve Jobs, explained in an email to the Free Software Foundation last year that a patent pool was assembled to "go after" a previous open-source format.
"All video codecs are covered by patents," Mr. Jobs wrote. "Unfortunately, just because something is open-source, it doesn't mean or guarantee that it doesn't infringe on others patents."

Several comments speculated about Microsoft’s financial interest in the codec. (Microsoft participates in MPEG-LA with many other companies.) Microsoft pays into MPEG-LA about twice as much as it receives back for rights to H.264. Much of what Microsoft pays in royalties is so that people who buy Windows (on a new PC from an OEM or as a packaged product) can just play H.264 video or DVD movies. Microsoft receives back from MPEG-LA less than half the amount for the patent rights that it contributes because there are many other companies that provide the licensed functionality in content and products that sell in high volume. Microsoft pledged its patent rights to this neutral organization in order to make its rights broadly available under clear terms, not because it thought this might be a good revenue stream. We do not foresee this patent pool ever producing a material revenue stream, and revenue plays no part in our decision here.