In an effort to resolve "uncertainty around video on the web" using HTML5, Microsoft has announced a new plugin for Google's Chrome browser that adds back support for H.264 video playback, blunting Google's attempt to gain traction for WebM.

The announcement ratchets up the war of words between the two companies, following a complaint from Google earlier this week that Microsoft's Bing search engine was appropriating its search results to improve its own.

By adding H.264 video playback back for Windows Chrome users, Microsoft's Dean Hachamovitch, the head of Internet Explorer development, said his company hopes to bypass a series of significant issues raised by Google's WebM strategy, related to intellectual property liability and risk, the open development of web standards, and simple video playback consistency.

Microsoft and Google, along with Apple, Mozilla and Opera, have been working for years to address the issue of how best to deliver video on the web. The newly emerging HTML5 specification enables publishers to simplify web audio and video embedding using media tags that hand raw multimedia content to the browser for playback (just like JPEG or PNG graphics files), rather than relying on a separate plugin architecture such as Apple's QuickTime or Adobe Flash to handle multimedia.

Commercial software vendors, including Microsoft and Apple, favor using the International Standards Organization's MPEG H.264 video codec, a mature and sophisticated specification developed by the technology community and offering consistent playback across the web, PC desktop and mobile devices because it is well supported by existing hardware. Other MPEG stakeholders, from Nokia to Sony (and realistically, every hardware maker), also favor H.264.

However, free software enthusiasts, principally Mozilla and Opera, have been pushing the case for Ogg Theora, a rival codec that is distributed by an organization that (unlike MPEG) does not charge royalties for its use. Ogg Theora isn't nearly as mature or as sophisticated, resulting in far less efficient distribution and a very limited use scenario only appropriate for low quality web videos.

Until last year, the situation appeared to be resolving itself as the market picked H.264 as the de facto standard for delivering HTML5 video. But last summer, Google threw fuel on the embers of the debate by acquiring the original developer of the proprietary codec that became Ogg Theora and releasing its newer sibling codec (VP6, rebranded by Google as WebM) as a new royalty free alternative to H.264.

While enthusiastically embraced by Mozilla, Opera and Wikipedia, most commercial vendors demonstrated no interest in switching to or even adding support for WebM in their HTML5 video distribution plans. Three weeks ago, Google announced plans to remove H.264 video playback from Chrome in an effort to push WebM to gain traction, again inflaming the situation and casting doubt on the prospects for the future of HTML5 video entirely.

Without consistent support for HTML5 video using a codec that every browser can play, video producers appeared forced back to supporting Adobe Flash for H.264 video distribution rather than using HTML5 at all, defeating a cornerstone feature of HTML5: its plugin-free support for integrated media playback. As critics pointed out, this would have no impact on whether H.264 were actually generating royalties, but only really impede the adoption of HTML5 over Flash as the vehicle for video on the web.

On page 2 of 3: H.264 vs WebM

H.264 an issue for free operating systems

The problem Google attempted to solve with WebM only affects web browsers that ignore their underlying operating system's support for media playback. Microsoft's Windows, Apple's iOS and Mac OS X, and Google's Android all natively support H.264 video playback. There is also unofficial support for H.264 playback on Linux, just as there is unofficial support for playing DVDs and other royalty-based content formats on that platform.

However, Mozilla's Firefox, Opera, and Google Chrome all ignore the underlying OS' media support to handle video themselves. For Windows users, Microsoft has announced H.264 support for Firefox via a plugin that reverses this behavior, and is now similarly adding back H.264 playback support for Chrome; both plugins take advantage of Windows' native ability to play H.264. This effectively neutralizes Google's efforts to force adoption of WebM.

Unlike Apple, Microsoft has said it will also support WebM in Internet Explorer 9 via a plugin. While WebM codec support can be added to QuickTime via a component plugin, Apple has shown no interest in working to push WebM as a standard because, like Flash, it is not supported on iOS devices and support cannot be added by third parties; Apple would have to do the work itself.

WebM an issue for mobile operating systems

Like Flash and Java, Apple has no interest in adding parallel support for WebM as an alternative way to play media content on its mobile devices, because doing so would require lots of duplicative work (for Apple, not third parties) just to add another, less efficient way to do the same thing its devices can already do.

Microsoft has no significant mobile business, so it lacks Apple's stern opposition in pushing a secondary web format that would complicate its efforts. Microsoft's Hachamovitch wrote that the company is "agnostic and impartial" about the actual video formats in use on the web, as long as they don't raise problems related to intellectual property liability and risk, the open development of web standards, and simple video playback consistency.

"Our support for H.264," Hachamovitch wrote, "results from our views about a robust Web and video ecosystem that provides a rich level of functionality, is the product of an open standards process like the W3Cs HTML5 specification, and has been free from legal attacks. Microsoft is agnostic and impartial about the actual underlying video format for HTML5 video as long as this freedom continues."

On page 3 of 3: Three WebM issues raised by Microsoft

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.

Woderful! Ironic that it is MSFT that comes with the heavy hammer on Google's head. Google is indeed the new evil! They take our data, without our permission, and make billions on it all the while being the whores of the internet. I never thought I would say this but THANK YOU Microsoft!

I'll see your irony and raise you one more! Didn't Google release a plug-in for IE that added support for some Google API for Wave or another mediocre thing they were doing? The plug-in basically installed the Google Chrome rendering engine as a plug-in to work in place of the non-standards engine used by IE. I remember because we all thought, "great! if everyone using IE installs this plug-in from Google, it will alleviate the headaches and hoops web designers have to jump through to get sites to work on IE."

So now MS is doing a similar thing to Google's browser because it doesn't want to play nice with everyone else.

I know, right?? What company would ever block a widely accepted technology from their product?! WHO?!?!?!?!?!?!?

You're thinking Flash, but Apple didn't block Flash in 2007; it simply didn't exist in mobile form capable of running any desktop Flash content until last year, three years after the iPhone was released.

Adobe didn't make a stink during that time because it couldn't say Apple was the problem. It was only last year, when Adobe wanted to sell Flash as a tool for making iPad apps, that Apple said, "no, we have no use for supporting your platform on the iPad because it doesn't work well enough," that Adobe flipped out.

Flash is not, like H.264, an open standard Apple can implement. It's also not a web standard. It's a defacto web plugin that everyone has been using because HTML itself lacked the ability to reference video. HTML5 solved that issue for iOS years ago, making Flash worthless to everyone apart from those invested in it.

So no, not really similar at all. If Flash were an open standard working on the iPhone, and Apple yanked it to promote its own thing, then you might have a case. But you don't.

Woderful! Ironic that it is MSFT that comes with the heavy hammer on Google's head. Google is indeed the new evil! They take our data, without our permission, and make billions on it all the while being the whores of the internet. I never thought I would say this but THANK YOU Microsoft!

I don't know if I see IE9 supporting WebM as a "hammer" coming down on Google. If anything its a win for Google because Microsoft isn't going to develop the plug-in for macs and I doubt Apple will either. Which makes it more likely that WebM will gain prevalence instead of less in my view.

I don't know if I see IE9 supporting WebM as a "hammer" coming down on Google. If anything its a win for Google because Microsoft isn't going to develop the plug-in for macs and I doubt Apple will either. Which makes it more likely that WebM will gain prevalence instead of less in my view.

Are you saying WebM will be more attractive to publishers because it won't work on Macs?

What about not working on any existing smartphones, will that be a good thing too? How about not working on iOS, how did that play out for Flash?

I agree with Microsoft on this completely. I think google made a wrong turn with dropping 264 and has wasted time and money on webm. Solid vide codecs take a lot of time and effort to develop. You can't just open source this and make sure it stays consists t and of high quality. We have a good way to play video that is supported by most devices and charges a reasonable royalty. I think it is a very good choice for the future.

Are you saying WebM will be more attractive to publishers because it won't work on Macs?

What about not working on any existing smartphones, will that be a good thing too? How about not working on iOS, how did that play out for Flash?

I think you misunderstood. WebM will work on Macs, because you can use Chrome on a mac, it will also undoubtedly be incorporated into Android and there for work on mobile. However Microsoft will not be making a H.264 plug-in for Chrome on Macs, meaning that if you want to use a codec that is supported in Chrome and IE on BOTH platforms you would use WebM. it will really come down to which browser is more popular in the long term and frankly I see Chromoe being far more popular than Safari, and since Firefox will also support webM

No doubt due to be pimped out on Googles home page which is one of the most popular urls in the world.

So to me as a developer, implementing WebM which will support Chrome, Firefox and IE, instead h.264 which will support IE and Safari makes more sense.

As for your Flash comment, not playing on IOS didn't really kill Flash at all despite the prognostication to the contrary.

What remains to be seen here is how much traction Google can really gain, both with Android and Chrome. The true story for technology has and always will be user adoption. If everyone is using it competitors have no choice but adopt it. This is what Apple, Microsoft and Google are all betting on.

You're thinking Flash, but Apple didn't block Flash in 2007; it simply didn't exist in mobile form capable of running any desktop Flash content until last year, three years after the iPhone was released.

Adobe didn't make a stink during that time because it couldn't say Apple was the problem. It was only last year, when Adobe wanted to sell Flash as a tool for making iPad apps, that Apple said, "no, we have no use for supporting your platform on the iPad because it doesn't work well enough," that Adobe flipped out.

Flash is not, like H.264, an open standard Apple can implement. It's also not a web standard. It's a defacto web plugin that everyone has been using because HTML itself lacked the ability to reference video. HTML5 solved that issue for iOS years ago, making Flash worthless to everyone apart from those invested in it.

So no, not really similar at all. If Flash were an open standard working on the iPhone, and Apple yanked it to promote its own thing, then you might have a case. But you don't.

Three words of explanation: Daniel Eran Dilger. And including multiple charts and/or tables (especially Venn diagrams!) also appears part of his contract.

And as I'm gathering, a real cheerleader, but also a really analytical cheerleader who does lots of homework, even if he tends to cherry pick his facts to generally make Apple look good or better or injured or vindicated or invincible, depending on the story. So somewhat a blowhard, but at times, one of the best synthesizers of tons of history and tech detail around.

Ergo, like Beelezebub for earth, a necessary part of the Apple rumors site universe.

My 2cents as critic.

PS: As for meaningless, you won't think so if one day it's announced YouTube will play on Android, but not on iOS devices.... ...not that Google would go that far (tho', in some parallel universe they doubtless already have!). The big Sumo wrestlers pushing each other around here are playing for more than minor leverage in this game. And the results will matter.

Quote:

MacRulez
Actually, if you read the article you'd understand that Bing is improving by lifting Google's search results.

Check it out - Google used a very clever honeypot solution to catch Bing on this. It's pretty funny, actually. A good read.

Apple needs to do the same for Chrome on Mac OS X. Chrome on Linux is left but with 1% share who cares.

I thought it was amusing that people posting to the MS blog complained that it doesn't support Linux. Linux users generally try to get away from Microsoft software, why would they use an MS plug-in if one was made? Even as a rhetorical device, the complaint is silly.

I expect there will be a solution for Linux users by Linux users. I'm just surprised that Microsoft made their own plug-in available sooner, of course with the respective OSs only.

Now it looks like Microsoft is siding with Apple to stick it to Google.

It's like how the US and Britain and France joined up with the Soviet Union to defeat Nazi Germany (I'd like my Godwin's Law prize, please). Apple, of course, is Team America (f***, yeah!), Microsoft is the USSR and that makes Google the Third Reich.

This is such an extraordinary set of circumstances if you look at the history of Apple vs. Microsoft for the past 25 years or so, but if you look at recent events, it starts to make sense.

Oh, well, this world has been fun, but next year I trust most of you are going to join me in Hell (bring Chap-Stick.)

What remains to be seen here is how much traction Google can really gain, both with Android and Chrome. The true story for technology has and always will be user adoption. If everyone is using it competitors have no choice but adopt it. This is what Apple, Microsoft and Google are all betting on.

They won't gain any traction. Why would content providers / web developers use WebM for Google's platforms when Flash is readily available and can serve up the H.264 video they already have? They're not going to switch to WebM simply because Google supports it through the <video> tag. It's completely ridiculous to think that.

Scenarios that will ultimately result from this...

1. If a web developer wants to do the least amount of work to make the biggest impact, they'll simply deliver H.264 video using Flash.

2. If a web developer is willing to do a tiny bit of work to make a bigger impact; deliver H.264 video using Flash and the <video> tag. One falls back on the other if not available.

#1 leaves out almost all mobile users. Yes Android 2.2 & 2.3 support Flash, but only about half of the Android installed user base is using either of those, and a chunk of those devices may not have the hardware to support smooth playback.

#2 covers just about everything, including most mobile users.

Disclaimer: The things I say are merely my own personal opinion and may or may not be based on facts. At certain points in any discussion, sarcasm may ensue.

Honestly, it is much easier for consumers if their video cam, computer, phone, web browsers all use the same video format. Consumers should not have to worry that there is even such a thing as multiple formats.

With this in mind, all the big companies (not just computer companies, but Nokia, Sony etc too) got together and agreed upon one. And Intel, in their latest Sandy Bridge processors, even have hardware support for quickly resizing this format, to easily make small sizes for email attachment. And video card makers have support to enable very efficient playback. It is a miracle of agreement and co-operation that this ever happened at all, and yet Google wants to ruin it for everyone.

Apple needs to do the same for Chrome on Mac OS X. Chrome on Linux is left but with 1% share who cares.

Apple doesn't need to care. Safari's deployment rate continues to steadily expand. Apple continues to expand HTML 5 with H.264 in all its devices which are selling nearly 250% greater than the rest of the industry.

Apple doesn't need to do the same for Chrome. Apple has provided mountains of code in WebKit for Chrome.

Apple doesn't need to care. Safari's deployment rate continues to steadily expand. Apple continues to expand HTML 5 with H.264 in all its devices which are selling nearly 250% greater than the rest of the industry.

Apple doesn't need to do the same for Chrome. Apple has provided mountains of code in WebKit for Chrome.

Apple has provided mountains of code for LLVM, Clang, Libc++, etc.

I hear that Safari does not perform well on Windows. It would be good to see Apple address that if it is true.