Wednesday, February 02, 2011, 06:20 pm
Microsoft announces H.264 support for Google's Chrome
Issue 1: Intellectual property liability and risk
The first issue Hachamovitch detailed relates is the protection of those who want to use HTML5 video. "Looking at video format support as a vote on who is for or against an open and free Internet is tempting but also naïve," Hachamovitch wrote, noting the reality of software patents and the minefield of patent infringement.
"There is absolute certainty that some parties believe they hold valid and unique inventions (patents) and they will assert those rights if they think they are being infringed," Hachamovitch noted. "Historically, providing new audio-video-image formats that are entirely free from infringement has been a lengthy and challenging process. Even when we have set out to do this ourselves, we have ultimately ended up being challenged."
That was an apparent reference to Microsoft's VC-1/Windows Media codec, which was found to infringe upon existing MPEG patents, ultimately pushing Microsoft to collaborate with MPEG as a royalty payer rather than fight against it. Microsoft has noted that it "pays into MPEG-LA about twice as much as it receives back for rights to H.264."
"Offers of 'free' or 'royalty-free' source code and strong assertions that the technology is 'not patent encumbered' dont help when a patent holder files a complaint that your video, your site, or your product infringes on her intellectual property. The only true arbiter of infringement, once its asserted, is a court of law. Asserting openness is not a legal defense," Hachamovitch wrote.
He then chastised Google for failing to indemnify WebM users from future patent attacks. "If Google were truly confident that the technology does not infringe and is not encumbered by patents whatsoever, wouldnt this indemnification be easy?" Hachamovitch also referenced Google's comment at its WebM summit that the new codec has "no known royalty requirements," adding, "thats quite different from no royalty requirements."
Hachamovitch also wrote that Microsoft "is willing to commit that we will never assert any patents on VP8 if Google will make a commitment to indemnify us and all other developers and customers who use VP8 in the future. We would only ask that we be able to use those patent rights if we are sued first by somebody else.
"If Google would prefer a patent pool approach, then we would also agree to join a patent pool for VP8 on reasonable licensing terms so long as Google joins the pool and is able to include all other major providers of playback software and devices," Hachamovitch added, perhaps inadvertently highlighting the fact that once WebM creates a legitimate patent pool it will, like VC-1, end up with the same royalty situation as H.264, the very "problem" Google is hoping so solve.
Issue 2: Open development of web standards
The second major issue addressed by Hachamovitch is where WebM came from, and what legitimately makes it a web standard. Rather than being the product of open, community development like MPEG portfolio standards, WebM is simply a proprietary codec Google bought and then "opened" as a suggested (but not official) standard.
However, as Hachamovitch points out, Google says that specification it released to the Internet Engineering Task Force was "not binding," and that only the actual implementation in code was. "Reverse engineering a standard from sample source code is a poor practice," Hachamovitch wrote.
That's a wildly new perspective to come out of the company that just pushed its proprietary Office document formats through a standards organization in a very similar way to create Office Open XML. In that battleground, Google has supported the rival OpenDocument effort, intended to create an open document specification that isn't just an "opened" version of Microsoft's proprietary format that may still be patent encumbered and has known issues between the standard in the specification and what exists in practice.
With WebM, Google's shoe is on the other foot, advocating as a "standard" something that actually originated as proprietary software developed without community input and which has no real standards backing apart from the code instance Google offers, which is known to differ from the specification it delivered to the IETF.
"What are Googles plans for turning WebM into a genuinely open standard, one that is based on consensus like the rest of W3Cs HTML5 effort?" Hachamovitch asked. "Separating the current implementations from the specification and test suites so that independent implementations are free to emerge from the community and compete and improve is a crucial step that the W3C has taken with HTML5. When will Google enable that to happen for WebM?"
Issue 3: Simple video playback consistency
Hachamovitch also threw down a third problem for WebM, asking, "Concerns for openness were key reasons given for removing H.264 support from Chrome. Android currently supports H.264 and there are no announced plans to drop it. Will Google drop H.264 support from Android?
"Is Google committed that YouTube (and other Google video services) will continue to work with devices that lack support for WebM? The lack of consistency across devices, Web services, and the PC is a challenge for the community."
Hachamovitch also noted hardware acceleration as being a key factor in preventing any attempts to quickly roll out WebM as a credible alternative to H.264.
"Developers want confidence that what they write will work for consumers. Consumers and businesses want confidence that video on the Web will continue work and that they will not face legal risk for using it. Googles decision to drop support for H.264 from its browser seems to undermine these goals," Hachamovitch concluded.
The future of HTML5 video
The unfolding situation between Google and Microsoft marks a dramatic role reversal in the two tech giants, one where Microsoft is standing up for community developed open standards and interoperability between devices, while Google is advocating the use of software it owns in preference to existing, superior standards adopted by the industry years ago, a decision that threatens to derail HTML5 and push web developers back to using Adobe Flash.
Google maintains that WebM is necessary because, "to use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royaltieswith no guarantee the fees wont increase in the future."
There's still the potential that Google could step up to the plate and pledge to indemnify WebM users from patent risks, something HP and Oracle have done for their Linux users. Google could also shift WebM to a neutral third party and set up a legitimate community of development. The core problem being that WebM is likely already infringing upon MPEG and other patents, and that there is little that can be done to modernize WebM without running into new patent issues.
Another alternative for Google would be to simply cover the licensing costs of H.264 for free and open source users, which is currently a small population. However, Google hopes to advance Chrome OS as an alternative platform for mainstream netbook and tablet users next year, and could be forced to pay for H.264 licensing in its free OS unless it can deliver an alternative in the meantime, making its willingness to support H.264 increasingly suspect.
On Topic: Software
- Avid announces Pro Tools 11 and Media Composer 7 for Mac & PC
- Adobe releases Lightroom 4.4 and Camera Raw 7.4 after month of testing
- New release candidates for Adobe's Lightroom and Camera Raw bring bug fixes, added camera support
- Apple to lock iOS app screenshots upon submission to halt scammers
- Firefox 18 launches with support for Retina display Macs