Real to Offer Open Source Windows Media for Linux

cpugeniusmv writes to tell us News.com is reporting that RealNetworks plans to release an open source method to allow Linux users to play Windows Media files. Currently Linux users are able to play the two main Windows Media formats (wmv and wma) but only if they install closed-source modules. The ability to launch this initiative comes from a recent licensing deal between RealNetworks and Microsoft and the antitrust settlement against Microsoft.

Re:already there?

[hamfactorial]

Yes, with the same caveat of requiring closed-source modules. In mplayer's case, codecs.

Re:already there?

[Anonymous Coward]

Actually, the latest ffmpeg can play WMV3, no windows dlls needed.

You will need to check out the latest ffmpeg svn and compile it tho.

Re:already there?

[Sharth]

non-x86 users can't use mplayer for wmv.

and afaik, it can't handle wmv10 drm.

ffmpeg already have this in the works!

[baadger]

The guys behind the ffmpeg/libavcodec implementation which mplayer, xine and VLC and a whole bunch of a/v media apps in Linux already make use of, already have a working and pretty good WMV3 (WMV v9 Video) implementation in CVS. Infact it'll probably trickle into distro's before the end of the year.

Yeah so, move along... nothing to see here.

Re:already there?

[hamfactorial]

x86_64 users have the option of compiling a 32-bit version of mplayer to use the 32-bit codecs from MS. You are correct about wmv10. It's not a terribly convenient way to do things, since 32-bit plugins can't be used by 64-bit programs (read: mplayerplug-in in 64-bit firefox). It's a big mess really, but it's hard to wean people from the .wmv teat. I've always loved ffmpeg for encoding, and I've heard that within the last week VC-1 decoding has been improved in ffmpeg to allow WMV decoding natively. Exciting stuff!

Re:That'll be great

[baadger]

The WMV3/VC-1 specification is formal and out there and is going to be used on Bluray/HD-DVD. They aren't likely to break compatibility willy nilly, not in the video profiles people care about anyway.

Re:Licencing issues...

[compm375]

Yeah, but can you play Flash 9 videos on Linux or even Flash 8? Does it work on x64, in an x64 browser?

Re:Licencing issues...

[nmos]

The last time I tried to download Flash for Windows the license was really obscene. Among other things it gave Adobe the right to audit my computers and also came with a list of devices and OSs that it was not to be used with including Windows MCE. These are just nuggets among something like 7-9 pages of legelese. A few pages in I just gave up and decided I didn't really need the latest Flash that bad.

Re:already there?

[jZnat]

Yes, but many people would have to agree that the binary codecs MPlayer supports really suck compared to the native ones. Besides, DLLs (common usage) only work on x86 processors, yet MPlayer is cross platform (so is Helix), so that doesn't solve the problem completely.

Re:False Summary

[jZnat]

I actually prefer Matroska [matroska.org], but I'd also like to mention that Apple's MOV container is pretty open and well documented [apple.com] (PDF warning), unlike Microsoft's crap.

Re:Licencing issues...

[agallagh42]

I just scanned through the Flash EULA at the Adobe site [adobe.com]. Either they've recently changed it, or you mis-interpreted it. I couldn't find any reference to auditing your computer, and MCE is specifically permitted.

Re:Satan:

[morgan_greywolf]

Actually, I personaly doubt they will release it using GPL, in whatever incarnation of the license. They are more likely to get OSI approval for an open source license of their own, just like SUN and IBM did. And considering the stakes here, the approval (or not) should be handled by the OSI board as high priority.

It's going into Helix Player, which is multilicensed [helixcommunity.org]. The two open source licenses it currently supports are the GPL and RPSL, their own OSI-approved license. You can also license it under a commercial license. The question is will they continue licensing Helix in this manner? Will they stop support for GPL? Or will they make the Windows Media Support a separate plugin that's not part of Helix and available under RPSL? I agree with you in that I think the last scenario is the most likely, IMHO.

Re:Helix Player?

[noldrin]

The Helix Player can use those codecs, but it doesn't come with those codecs. When you download the open source Helix Player, all you are getting are the open source codecs which does not include the real formats. If you download the closed sourced Real Player for Linux, you are getting a closed source Helix Player which includes all the closed source real formats. Also this player is crap and plays Real files and MP3 files so slowly that my machine skips every 3 to 7 seconds when player Real files, and can't refresh the player while playing an MP3. MPlayer using Real's codecs does not have this problem at all. Also the RealPlayer for Linux can't play older formats, while MPlayer using Real's Codec's can.

Re:Satan:

[Anonymous Coward]

Maybe I'm wrong about this, but this is how I've aways thought it worked.

Unfortunately you _are_ wrong. Case point: Go to http://www.mp3licensing.com/royalty/ [mp3licensing.com] and behold the royalty rates for a "decoder". Note that this patent is generally ignored but some more careful distributions like Ubuntu do not support mp3 playback out-of-the-box for that very reason.
I assume your misunderstanding is the result of the situation with the LZH-algorithm, or in practical terms, the GIF format. Thos, now expired patents only covered the LZH encoding not decoding, hence one could make, use and distribute a decoder but not an encoder. However this was just the special situation with regard to these 2 patents covering this particular algorithm, i.e. they were luckily (from the patent holder's point of view, unluckily) worded in such a way that they only covered the encoder.

Nota bene: Yes, there were indeed two patents covering exactly the same algorithm, one was held in its latter days by Unisys and was the more notorious one due to Unisys' active enforcement. The other one was held by IBM and just recently expired but IBM never actively enforced it (It would've probably fallen due to prior art anyway but it does illustrate the utter stupidity of the USPTO specifically and the patent system, especially with regard to software, generally).

Re:Satan:

[Schraegstrichpunkt]

For reference, the actual algorithm is LZW (Lempel-Ziv-Welch), not LZH. LZH is compressed file format (similar in function to ZIP) generated by old versions of LHarc.

Re:That'll be great

[ajs318]

Yes it does.

You -- the rightful recipient of an encrypted message -- have to have all three of the following: the encrypted file, the decryption key and the player {which contains the decryption algorithm}. Without the file you have nothing to watch / listen to, without the key you have no way to decrypt it and without the player you have no way to view / hear it. If you had the source code to the player, you could find out where the key is obtained from {it might be in the encrypted file or it might be in the player itself} and use the decryption algorithm independently to decrypt the file.

Of course, reverse-engineering a binary-only program is possible -- it's just not easy. DRM is fundamentally flawed {in the worst case, it can be defeated with cameras and microphones}. This is likely to persist until we get schemes that perform the final decryption in your brain.