A Closer Look at the Microsoft h.264 Extension for Chrome

Today I took a closer look at how the “Windows Media Player HTML5 Extension for Chrome” works. To recap for a moment, Google announced that they are revoking native h.264 playback for the HTML5 <video/> tag in Chrome. A huge kerfuffle ensued. Yesterday, Microsoft announced that they were providing an extension to Chrome that provides h.264 support for the <video/> tag in Chrome on Windows 7.

I downloaded the CRX file and unzipped it. This is the contents:

PS> ls | select Length, Name | ft -AutoSize

Length Name
------ ----
  6540 contentscript.js
   678 manifest.json
163256 np-mswmp.dll
 59413 wmp eula.rtf
  3489 wmp releasenotes.txt
 28177 wmp128.png
   569 wmp16.png
  2233 wmp48.png

The np-mswmp.dll file looked familiar. And that is because it is the NSAPI plugin for Windows Media Player for Firefox.


The remaining interesting file in the CRX is contentscript.js. In a nutshell, what this script does is look for <video/> elements that are referencing h.264 or WMV content and dynamically replace them with <object type=”application/x-ms-wmp” /> element referencing the same content.

Interesting Side-Effect

The Windows Media NSAPI plugin is installed into Chrome along with this extension which means any pages which explicitly embed the Windows Media Player will work.


Also, this extension enables support for WindowsMedia Video content in <video/> elements.

var supportedMimeTypes = ['video/mp4', 'video/x-ms-wmv'];
var supportedVideoExtensions = ['.mp4', '.wmv', '.mp4v', '.m4v'];

Windows 7 Not Really Required

The Windows Media NSAPI plugin was released by the Port 25 group at Microsoft in April 2007. It doesn’t rely upon Windows 7 to work. The issue is just that Windows 7 is the first version of windows to ship with an h.264 codec for Windows Media Player. The extension should work on Windows XP and Vista if you have an h.264 codec for Windows Media, such as from the K-Lite codec pack.

Pointing the Way for Alternate Cross-Platform Implementations

This general approach also points the way for a 3rd party that has an NSAPI plugin that supports h.264 to extend Chrome (and Firefox) to support h.264 and whatever else the video player can support in the <video/> element. In particular it should be straightforward to create an extension that uses the VLC NSAPI plugin to extend the <video/> tag codec to support h.264 as well as DivX, QuickTime and MPEG-2.


Microsoft Puts h.264 Back into Chrome

Is I suspected they would, Microsoft has released an h.264 codec extension for Google Chrome to support h.264 in the <video /> tag. They provide the same mechanism for Firefox.


This Extension is based on a Chrome Extension that parses HTML5 pages and replaces Video tags with a call to the Windows Media Player plug-in so that the content can be played in the browser. The Extension replaces video tags only if the video formats specified in the tag are among those supported by Windows Media Player. Tags that contain other video formats are not touched.

The Extension also checks if the browser version already supports MP4 (H.264) video codec, if so the extension is not used.



Any browser running on Windows can play H.264 video via the built-in Windows APIs that support the format. Our point of view here is that Windows customers should be able to play mainstream video on the Web.



Shocking: Google Removing h.264 Support from Chrome

To that end, we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

via The Chromium Blog

I’m very, very sad to see this announcement. h.264 is the web video standard while WebM is a new Google codec that nobody uses and nobody uses Theora. We really don’t need video codec fragmentation in HTML5. The likely result of that will just be standardization on Flash video. Do we get to re-hash the video format wars of the 1990s in the 2010s?

This sucks and basically shows that HTML5 is not standardized and not ready for prime time. Not cool at all.

This is an opportunity for Microsoft to look like a hero and fix this for Google like they did for Mozilla.

Mass-converting DVD collection to h.264

My wife and children and I have amassed a large DVD collection. It started out as a protest against District CableVision (now Comcast). Now the collection nearly fills two book shelves floor to ceiling and it is a big heavy pile of plastic. We have a tight weight allowance for shipping to Ghana and I want to jettison the weight without losing the content.


Enter Handbrake. Handbrake is really good at transcoding DVD to h.264 but it doesn’t deal with the encryption schemes that some vendors have included. On Linux and Mac, Handbrake will use libdvdcss from VLC if present but not so on Windows. On Windows, the tool of choice is Slysoft AnyDVD.

I’ve learned a few things.

First, it takes a lot of CPU time to transcode h.264 video and a nice movie conversion is in the ballpark of a gigabyte in size (+-20%).

Second, some of our DVDs, particularly the ones my kids have handled are messed up. I have had to reconstruct one using ISO Buster which is also a cool program to have around.

Third, the copy protection schemes on DVDs include not only encryption with the Content Scramble System (CSS) but also deliberately mastering the disks with bad sectors and other errors. Disney seems particularly into this method of selling broken DVDs. It is a miracle the damn things even play in a DVD player, which as it happens, sometimes they don’t. We had an older Bose DVD player that couldn’t play Snow White or Peter Pan. We had to use VLC to play those discs. It could only play Mary Poppins if you hit a magic sequence of skip and menu on the remote. We eventually bought a new Samsung DVD player to fix the problem but it seems likely that the real problem was that the discs are mastered with bad sectors on them.

Fourth, corollary to the first point. It takes a long time to transcode to h.264 but if you aren’t there to swap discs, the computer can sit idle for hours. It also sits idle most of the night. The key to keeping the processor burning is to rip the VIDEO_TS directory to hard disk (and remove encryption in the process). The rip runs at just about whatever the maximum speed of the DVD drive is. You can then schedule a huge transcoding queue with Handbrake. I have 3 computers running 24×7 in a race to get as many DVDs converted before we pack out.

This whole scheme of copy protection and making broken discs on purpose really pisses me off. I feel like I have purchased defective manufactured items and am having to fix them myself. If these content producers wanted to provide a good experience for me who pays them a ton of money, they would figure out a way to deliver h.264 files for every DVD I have ever purchased. And if they really wanted to keep my good will, the downloads would be in HD.


Why is Handbrake’s logo some kind of tropical fruit drink and a pineapple?

%d bloggers like this: