Google removes H.264 support in Chrome

The official codec for HTML5's video tag has been under debate ever since developers began adopting the new technology. A current standard, H.264 was a codec thought to be just perfect for use in the video tag, so perfect that Microsoft even announced Internet Explorer 9 will only support the codec for their HTML5 video tag. Google however has other plans for what codec will rise above the rest.

Google will begin phasing out H.264 support in Chrome over the next couple of months, Product Manager Mike Jazayeri writes on the Chromium Blog. Chrome will instead support their own codec, WebM (VP8), and the outside Theora codec as both are "completely open codec technologies." The changes made to Chrome in the next few months will allow for support of these codecs simply via the HTML5 video tag.

Reasoning behind removing H.264 from Chrome is that it, while playing "an important role in video," it is not truly an open codec like WebM or Theora technologies. H.264 was under fire last Fall for fears that people would be forced to pay royalties to use the codec. MPEG LA confirmed that H.264 will stay royalty-free to help create a standard for web video that all vendors could access with their mind at ease.

Google apparently is not satisfied enough, and only wishes to support truly open technologies as a goal of the company is to "enable open innovation." The search giant wishes to keep everything as open as possible, and with H.264 having patents owned by Microsoft and Apple, Google did not see that as fitting for their open web.

Report a problem with article
Previous Story

Video reveals updated Verizon iPhone hardware

Next Story

Tutorial: How to add your own themes to a HTC Windows Phone 7

151 Comments

View more comments

ichi said,

With both Nvidia and AMD backing WebM you can bet it'll be HW accelerated pretty soon.

I am not buying a new PC just to stroke Google e-peen.

My netbook and my notebook both can play high bitrate 1080p h264/AVC video just fine, if you are willing to bend down and take it up the bleep that is your own problem.

Udedenkz said,

I am not buying a new PC just to stroke Google e-peen.

My netbook and my notebook both can play high bitrate 1080p h264/AVC video just fine, if you are willing to bend down and take it up the bleep that is your own problem.

You don't have to, although you'll eventually do, same as you bought hardware that accelerated h264. Not because it'll accelerate WebM, just because you'll upgrade and all hardware will support it (like, say, a new smartphone with a Nvidia Tegra2).

FWIW, see how much I bend to this kind of video stuff that my GPU isn't even able to accelerate h264

"...H.264 was under fire last Fall for fears that people would be forced to pay royalties to use the codec..."

Unless the user is running Windows7, then Microsoft has already covered the licensing for you.

Google's ties to the restrictions of bad OSS licensing is going to tie their hands and might even strangle them, as it has a lot of brilliant OSS projects.

With the licensing Google has to use because of their Linux and OSS ties they will never be able to offer any proprietary technologies properly. This is what is happening here as well, because they can't include or properly license and include H.264 on their own platforms like Android, let alone for Chrome on other OSes.

Chrome on Win7 would be the exception, as the licensing for the codec is something Microsoft provides to the users and the developers on Windows7, as with all the new codecs added in Windows7, it is something users and developers don't have to worry about.
(This is also true of WP7 that also has a large number of licensed codecs handled by the OS, unlike iOS and Android where codec support at the OS level is limited and additional codec support must be provided via 3rd party software, new codecs can be added to WP7 at the OS level so that all applications get access to them inherently.)

This was smart for Microsoft to pay the codec fees and include them in the OS for Win7 and WP7; however, this is NOT something Google can do even if they wanted to for Android or any of their OS distributions based on the OSS kernels like Linux and the licensing restrictions.

Sadly, their codec choice is not the best codec out there, and sometimes the proprietary codecs are worth the licensing fees. So instead of OSS giving us 'progress' in terms of video quality it is 'regressing' our video quality and 'choice' of video quality.


An additional problem this creates...

Most GPUs are designed to decode and accelerate a handful of codecs, and this is not one of them. So by using this video codec, a lot of systems will take a hit in either performance or battery usage. This is major problem when considering mobile phones and devices where the lower end GPUs do have codec acceleration built in, but will not accelerate this codec.

Ironically again, Windows 7 desktop/portable devices won't have the same hit in performance or battery usage as Windows 7's WDDM architecture can supplement the GPU's dedicated acceleration. (OS X, iOS, Android, Linux, WinXP can't do this, and will take the hit. -WP7 may or may not take the hit, I don't know how WinCE 7.0 handles the supplementing codec acceleration beyond the GPU abilities.)

So...
I wonder what the other browser providers will do, as Microsoft has the ability to drop in this codec for IE9, so if this is what people want, Microsoft has the option to add additional support for this codec for HTML5. Maybe Microsoft should just say screw it, and adopt VC1 as the standard and watch others scramble, as IE9's HTML5 performance is going to give them one hell of a leap over the other browsers as HTML5 and newer web content becomes the norm.


I also don't like the H.264 licensing and what the future could hold; however, we already jumped down the rabbit hole with MPEG4/H.264 and VC1 being the default HD codecs for BluRay and most HD content distribution.

Now that we are here, it is a little late for Google think they are big enough to write the 'accepted' standards themselves. If you think about it from 'content' alone, this would create a lot of work and a nightmare for media companies in re-encoding tons and tons of video just so that you can view it in your Google browser...

have never worked with HTML 5 still, but i think not agreeing on standard is an addition headache for developers.

I really don't think Google cares about the Windows users. They've banned it from use by their employees on their work computers and are developing their own OS based on Linux. I'd say Google's trying to set their own standards and do their own thing rather than go along with what everybody else is and has been doing for decades now.

CoMMo said,
I really don't think Google cares about the Windows users. They've banned it from use by their employees on their work computers and are developing their own OS based on Linux. I'd say Google's trying to set their own standards and do their own thing rather than go along with what everybody else is and has been doing for decades now.
Considering most people that use Chrome also use Windows, I'd say that isn't the case. A lot of people are forgetting that in addition to Chrome, other browsers such as Firefox and Opera don't have built-in support for H.264. The same browsers also support WebM.

The way I see it, Google is thinking long-term. Last I read, H.264 is royalty-free up until 2015. After that, the MPEG-LA will start charging royalties. WebM, on the other hand, will always be royalty-free. Of course, that isn't the point of it. The point is, it's a container for codecs (VP8 + Vorbis) that don't require Flash. The only requirement is an HTML5 browser.

Thinking long-term, it's a step forward. Unfortunately, it isn't a step forward in quality and performance.

I'm not surprised. Android 2.3 has built-in support for VP8 and WebM. Also, I read somewhere that Adobe will update Flash to add support for VP8. As for the codec, it's definitely a step back in terms of image quality and performance; however, it's a step forward for open codec technologies.

Right now it's a battle between Google and Microsoft. The former wants WebM to be dominant and the latter wants H.264 to be dominant. As for me, I just want a royalty-free codec with good image quality and performance.

People were complaining on MS for pushing own standards into web. Now, when MS follow standards they can switch on Google.

Bad thing to do. Now we will definitely have to process a video 3 fecking times to make sure if can be viewed on all devices/browsers. Son of a b.....

Come to think of it, all YouTubes videos have been in H.264 as they have to support hardware accelerated mobile devices. Another transcoding job to get everything in WebM that no one will watch? Good move.

The problem is licensing. Sure H.264 is royalty free at the moment but once it becomes the standard there is nothing stopping MPEG LA from demanding royalties. I agree with Google in principle.

MindTrickz said,
The problem is licensing. Sure H.264 is royalty free at the moment but once it becomes the standard there is nothing stopping MPEG LA from demanding royalties. I agree with Google in principle.

But it's worth it.

Can't browser makers do the same as IE and use whatever codecs are provided by the platform, and add their own if necessary?
Having a software that runs on multiple operating systems is nice. Sacrificing everything in name of cross-platform compatibility is ridiculous.

I hope they won't be stupid enough to remove h.264 support from Android aswell, in that case my HTC Desire will be almost useless since h.264 is hardware accelerated and really helps when playing high resolution video & as already mentioned in this thread, a lot of handsets have h.264 hardware decoding built-in. Google, get a grip for Gods sake!

ah the idiocy I see here amazes me.

1. Ogg vorbis is superior to mp3 in every way other then the fact that ****ty players dont support it, quality players from quality companies tend to offer vorbis support, using current encoders a 96k ogg file sounds better then a 160k mp3(this is in my own testing with quality gear, also had 3 other people rate the codecs)
saying vorbis is crap because your zune or ipod or cheapo stick drive mp3 player wont run it is like saying flac sucks.....but the worlds full of idiots.....

2. by the time html5 go's mainstream vp8 will have matured alot, we have at least 3-5 years before html5 support will even be a real issue, all you morons saying your going to dump chrome because it wont have built in html5 h264 support really must be thick, or be using some form of the internet that nobody else is currently on.

3. vp8 video can be run on as low as an arm7 cpu (old ass cpu like used in old ipods) smoothly, I have seen demo's of it being done, thats at lower res(normally native to the device) but when compared to the same quality h264 video the vp8 decodes faster because they already have arm accelerated decoders for vp8.

I do agree that currently vp8 is inferior per bitrate to h264, no doubt, but its also just come into the public domain(meaning the worlds just gotten their chance to start working on improoving it), with google, amd,nvida and a slew of other companies backing webm I dont see it staying in the state its currently in for long.

please note how many years its taken for x264 to come of age, I have been around most of that time, and at first, it was no better then xvid quality wise, over the years its become the best video encoder out there, and x264 is still missing features, most notably x264 does not support Adaptive MBAFF (Macroblock-Adaptive Frame/Field) for interlaced videos, thus sacrificing a lot of coding efficiency in interlaced mode. all other major implementations support this feature.

again, just give vp8 some time, it will mature, and again, the vorbis side of things is already very mature and offers superior quality per bitrate to any other lossy codec.

P.S. vorbis is actually more efficent to deciode then MP3, as proven by tests of battery life under current builds of rockbox, http://www.rockbox.org/wiki/SansaRuntime any device that gets worse batt life with vorbis then mp3 has a poor vorbis decoder

Commenting is disabled on this article.