Moonshine is a project based on Moonlight that leverages the built-in Windows Media capabilities of Silverlight to bring Windows Media playback to Linux in a fully legitimate way, without forcing the end user worry about what a codec is. This is possible because Microsoft provides the codecs directly to all Moonlight users, regardless of their choice of Linux distribution.
Very simply, Moonshine:
- Allows an end user to experience Windows Media content on the web.
- Brings Windows Media playback capabilities to a user’s desktop for playing local/arbitrarily downloaded content.
On the Moonshine page, there is an XPI available to install for Firefox. You must have the latest Moonlight installed and Firefox 3.0 or newer. The Firefox shell that provides local media playback however is not part of the XPI. You must build Moonshine from source to have this feature. Packages will soon be available for openSUSE, and hopefully for other distributions soon.
Additionally, you must disable the Totem GMP/Windows Media plugin in Firefox, since it basically tells Firefox it can handle the same Windows Media mime types, even if the codec is not installed for GStreamer. It would be really great if Totem would only advertise mime types that GStreamer actually supports on a given user’s system.
The project consists of three components:
- A Firefox/NPAPI plugin written in C that claims support for Windows Media mime types and enables embedded playback of Windows Media on the web.
If you do not care about the really technical details of Moonshine, I’d advise you to stop reading now, and just install Moonshine and try it out! If you’re interested in the details of my life over the last month, read on!
The Silverlight Application
GtkScale, hastily of course.
MTK even supports a small level of native look-and-feel integration by reading system/theme colors from the browser’s CSS mapping.
It was still a really entertaining hack:
All this effort was necessary as unfortunately Silverlight 1.0 (which Moonlight currently targets) does not offer a toolkit – it really is just a glorified canvas/stage. When Moonlight 2.0 is released, the MTK side of Moonshine will go away, though it would be very interesting to re-target MTK from XAML to say, SVG. I would love to see someone try that, it should be relatively straightforward.
The Firefox Plugin
The implementation details on the Moonshine plugin are a bit interesting:
Moonshine provides the 4 standard NPAPI entry points:
NP_GetMIMEDescription. It proxies each of these calls, excepting
NP_GetMIMEDescriptionto Moonlight’s own NPAPI entry points.
NP_Initialize, Moonshine calls Moonlight’s
NP_Intialize, and then overrides three NPP functions to be returned to the browser:
NPP_StreamAsFileoverride simply prevents Moonlight from receiving that call, which would cause Moonlight to try to load WM content as XAML. The
NPP_Destroyoverride just allows Moonshine to clean up its Moonlight binding on an instance, and then call’s Moonlight’s version of the function.
And finally, the juicy
NPP_Newoverride actually creates its own NPP_New call against Moonlight. All it sends to Moonlight is the width, height, and HTML DOM ID of the requested WM player, and sets the
So this all means that Moonlight has absolutely no idea that the content its driving wasn’t hard coded in the web page. For all Moonlight is concerned, Moonshine is the browser. Plugins helping plugins, that’s what it’s all about.
And it all started as an extension
Moonshine was a really annoying project at first, and it took a while to come together. Most of the real progress and code that ultimately became Moonshine was written over the last two weeks.
Originally I wanted to avoid writing an NPAPI plugin and instead opted for writing a Firefox extension. What a mistake. I have learned way too much about Firefox and the Mozilla platform. It’s huge. But I must say, it was actually pretty pleasant to work with. Most APIs are pretty well documented. MDC is your friend, but a checkout of the Firefox source code is your better friend.
The mistake isn’t really the fault of the Mozilla platform, but a misunderstanding on my part of what I really needed to accomplish. My original version listened to the DOM, listened for new streams, etc. to intercept Windows Media mime types. This finally was working fairly well, but really was just a giant hack. I could not stomach the abuse I was causing inside the browser, and in no way was comfortable with releasing it.
However, the final nail in the extension approach was when I encountered web sites that actually check the plugin registry for a Windows Media plugin, and do not even create DOM content I could bind to if no plugin exists (ahh, gotta love the web). And of course the only way I could find to actually modify this registry was to be an NPAPI plugin.
Going Forward, Looking Back
It’s been a very interesting few weeks, but I am so tired of working on this. I am aching to get back to Banshee. I do however want to make this work on the Mac under Microsoft’s own Silverlight. Or maybe someone out there can do it for me? It would be a fun hack!
Additionally, I am pretty interested in MTK, but can’t afford to work on it. I would be absolutely thrilled if someone would rebase the code on top of SVG. SVG needs a toolkit! It’s pretty pointless to continue working on MTK if it just targets XAML, since Silverlight 2.0 provides a toolkit. Any SVG/HTML5/Canvas enthusiasts out there are more than welcome to the MTK code. Keep me posted!
UPDATE: Last night I fixed a bug in Moonshine that prevented Moonlight from downloading the Windows Media codecs if you were running in plugin mode. If you experienced a “Bad address” error, please install the 0.2 XPI.