I was visiting ossguy’s blog today when I noticed that he took a small break from the usual “Free Software Über Alles” rhetoric to post a useful investigation of the Microsoft binary codec pack that corresponds to Moonlight, Linux’s free implementation of Silverlight. At first, I was surprised to hear that this codec pack was finally available– I didn’t think it was going to be generally available until Moonlight’s official release. A little digging revealed that Moonlight 1.0 was officially released yesterday. I wondered why I hadn’t seen anything about this on any major Linux news sites yet.
Apparently, no one cares.
Well, I care, insofar as this is another way to study some codecs. I think it’s really slick that the codec pack is one monolithic, relatively small, binary blob that contains all the proprietary codecs needed to support Silverlight. ossguy’s post details 2 more-or-less direct download links:
- x86_32 version: silverlight-media-pack-linux-x86-5-1.so @ http://go.microsoft.com/fwlink/?LinkId=133186
- x86_64 version: silverlight-media-pack-linux-x64-5-1.so @ http://go.microsoft.com/fwlink/?LinkId=133816
I see that compn is already on the case, identifying the precise codec formats that this blob is designed to handle: wma1, wma2, wma3, wmv1, wmv2, wmv3, wmav, wvc1, and mp3. So, really, nothing interesting for our cause. Almost all of those formats are already supported in FFmpeg. The one that isn’t — WMA3 — is in progress via a Summer of Code project. Who knows? Perhaps this codec pack could yield some new intelligence. But I tend to think the previous binary decoder released for Linux — packaged with Linspire — was pretty thorough in its presentation of symbols.
This codec pack is pretty thorough in the symbols department as well. Run ‘strings’ against the blob to see the ASCII strings. Filter the output through ‘c++filt’ as this will demangle (official technical jargon) the C++-style names:
strings file.so | c++filt
And if you want to disassemble the binary, here is a little something I wrote up regarding the bare essentials of ‘objdump’ as applied to reverse engineering work.
At the very least, I can see this codec pack being useful for hooking up to FFmpeg in order to gather a baseline for profiling to see how FFmpeg’s decoders stack up. Further, I should be able to use it to decode reference samples to verify how close FFmpeg decodes, e.g., WMA 1/2 data to the original.
Whatever the case, I have started a MultimediaWiki page to describe the API.
> Further, I should be able to use it to decode reference samples to verify how close FFmpeg decodes, e.g., WMA 1/2 data to the original.
This would be nice. I did the same thing on Windows a while ago for WMAv2 while porting the code. WMAv2 in ffmpeg fails rather noticeably on many (all?) very low bitrate files, but is extremely accurate above about 16kbps or so. Rigorous testing might encourage someone to fix it.
Does it contain wma voice? That is still missing in ffmpeg.
File a bug report regarding the lowbitrate wma files and I will try to fix the bugs.
Does it decodes Windows Media Audio Voice, which was never RE’d?
The string “voice” doesn’t occur in the modules. I don’t know if the codec goes by any other aliases. However, various strings with “lossless” show up. Perhaps the thing is capable of decoding Windows lossless audio.