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.

ns-wmp

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.

wmpChrome

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.

http://www.interoperabilitybridges.com/wmp-extension-for-chrome

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.

 

http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx

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.

 

Interesting.

Can Google Sidestep Oracle Patent Payouts with Mono/C#?

android-monoOracle has sued Google over patent and copyright violations related to Google’s use of Java technologies in Android. Oracle acquired the Java IP as a part of its acquisition of Sun Microsystems. The details are somewhat different but this has the same general flavor as when Sun sued Microsoft over its non-conforming Java runtime and J++ language compiler. That lawsuit was based in contracts law because Microsoft did license Java from Sun and violated the terms of the license. In this case, Google has attempted to sidestep the licensing requirements of Java with their Dalvik VM. Once could reasonably argue that the technical basis was similar. Both Microsoft and Google want to achieve significant performance improvement and platform integration over a vanilla JVM at the cost of incompatibility with the Java standard. It’s not entirely clear that Davlik actually achieves superior performance, though. I have to wonder if the stack-based VM concept was incidental to the goal of making an end-run around J2SE runtime licensing requirements.

One intriguing—if a bit self-serving and improbable—proposal has been floated by Miguel de Icaza: Why not just replace Dalik with Mono, the free and open source implementation of Microsoft’s .NET? The Mono runtime is LGPLv2 and the class libraries are MIT licensed. Additionally the .NET Micro edition has been placed entirely under the Microsoft Public License which is a BSD-style license with an explicit patent grant. The Microsoft Community Promise explicitly indemnifies patent claims against anyone wishing to implement C# and the CLI and unlike Sun’s patent grant for Java, embrace-and-extend is OK—you can implement a superset of the C# and CLI features and you are still covered.

Google definitely has the wherewithal to migrate Android from Dalvik to Mono if they want to. They could make it a seamless transition and even migrate the bytecode of existing Dalvik (or Java) apps to IL. They could also provide a tool to migrate projects from Java language to C# as Microsoft did. Other implementations exist.

I think it would be pleasantly symmetrical if history repeated itself. Sun’s lawsuit put the kibosh on Microsoft using Java the way it wanted and essentially gave birth to C#, the CLI and the CLR. It would be ironic if history repeated and Android just adopted Mono as its runtime. The road is much easier to tread this time around because a fully open source implementation already exists and it has already been ported onto Android and bytecode-to-IL and Java-to-C# tools exist and are mature.

Dogpile on RIM

RIM caved to pressure from Saudi Arabia and will be installing servers there that can be monitored by Saudi authorities. Now, India has given RIM until August 31 to make a similar concession or have service suspended. I’m sure RIM will capitulate in order to stay in business. This is an unhappy precedent.

India is apparently also threatening to shut down Google and Skype messaging services unless the Indian government has the ability to intercept and monitor traffic.

Clearly, we need ubiquitous, secure and easy-to-use peer-to-peer cryptography so that governments have no central actors to put pressure on. Maybe the solution is OpenPGP but it needs to be much easier for people to use.

Follow

Get every new post delivered to your Inbox.