Posted
by
kdawson
on Tuesday January 16, 2007 @07:42AM
from the free-as-in-not dept.

Several readers wrote in to tell us that the open source media software development company Fluendo has announced plans to sell native Linux implementations of proprietary video codecs such as Windows Media, MPEG-2, and MPEG-4. (Press release here.) From the article: "Currently, many Linux video applications facilitate Windows Media video playback using Windows DLL files and Wine, which provides suboptimal performance, particularly with streaming video. Fluendo's codecs could potentially provide better integration for streaming Windows Media playback in Linux web browsers as well as through GStreamer-based desktop applications like Totem."

2) I guess a native binary blob is slightly better than a MS coded binary blob.... but frankly, it's still just a binary blob. You have no idea what its really doing.

I guess the vast majority of end-user couldn't care less what their video codec is doing, as long as it plays their damn video's. It's a bit like the NVidea Linux drivers: the free software purists see it as something awful to load a binary driver on Linux, but I for one am very grateful to have proper 3D accelerated drivers at all. Same goes for video playback... There will always be proprietary video codecs, just get over it. I don't see the problem anyway, if I'm want to run commercial software on Linux it is usually binary as well. Does that mean the software is useless or bad?

"the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely

Anyway, bringing nvidia into the discussion is a red herring, there is a huge difference between running a binary blob in ring 0 and userland. Let's discuss userland binary rather than kernel mode binary.

I got hit by the file corruption bug in that's existed in recent 2.6 kernels due to race condition. Was burried pretty deep, took the experts a while to figure out what was going on. I had the source code, so did thousands of other people. The bug still caused lost files. The nvidia driver's a pretty complex piece of code, having to handle many slight differences and implement workarounds for many different cards and chipsets. Nvidia have paid people on the job, with the relevant experience. What makes people think that the oss community can do a better job than nvidia's own people, when they can't even keep their own codebases bugfree? Bugs happen, and with really complex code, it takes people with the most experience available to find and resolve the problem, properly.

So hundreds of developers (and being kernel hackers, probably paid) took a long time to find a file corruption bug that would presumably affect a lot of people. And somehow you think that NVidia's little graphics driver team should be able to magically resolve your problems overnight?

Noooo, missed my point - there may be those hundreds of developers that work on the kernel, but it took the very select few, that had the proper experience and knowledge of the code and design, to track it down and fix it. The team of kernel developers could have been 5000, or it could have been 5. Sometimes, it's not the hands and the eyes, it's the right hands and the right eyes. Experience is very important in a complex codebase.

"I think you over estimate the number of people involved in the Linux / BSD nvidia driver"

No I wasn't trying to make any assertions as to number of people involved, I was just using the numbers 5000 and 5 in regards to the kernel to demonstrate the idea that having loads of manpower involved in something doesn't mean that they can all solve these various problems, there may only be 1 in 1000 that have the experience and knowledge of internal design etc required to fix it. The linux kernel is huge, and bugs

OMG!!! They could have been the one's who put it there deliberately in the first place!!! We all know that nvidia works with the government... they've probably put backdoors in the chipsets too! Damn I gonna rip out my nvidia graphics cards and not put them in until I have personally verified each line of code, and every single transister on the chip schematics, and every single transistor and wire and line of code that controls the machines that make them... THEN I'll know I'm safe. It's a good job I have as much experience with GPU design as nvidia and ati, as that means I'll definitely find whatever's there.

There are many cases where oss does seem to be providing us with better software, many many cases, no argument there. But when you start getting more specialised, what matters is experience with the specialised target, not brute force manpower.

You'd think that, wouldn't you? Designing and implementing the software - you're right, in general. But in terms of finding bugs, frequently an outsider does better. It's practically a cliche in programmer circles that the bug you've been fruitlessly hunting for two

Does this patch [nvnews.net] in the FreeBSD nVidia forum fix it for you? It helped me on a 6-STABLE system with the 9631 driver even if the patch said it was for 7-CURRENT and the 9746 driver. I recommend it.

Well, normal users are always more interested in what the code can do today, rather than what it could do tomorrow. Strangely there's a very good corrolation between what the normal users thinks of it tomorrow, and what the coders are able to do in the meantime. We've already tried a system full of binary blobs, it's called Windows or OS X. A few like nVidia are tolerated because a partially free machine is better than a useless machine since there's no real choice but in the long run fewer, not more blobs

I care. While I'm not likely to check the code for trojans and security flaws, I am likely to tinker with it.Sometimes I need a feature in software that's not already there. Other times, I need to tinker with some hardcoded value or behavior. (Like the time I needed to modify wget to get around a broken robots.txt.) One time, I wanted to use xvidcap, but found that the latest version of the code was old enough as to not compile on a modern GCC. (I'd be happy to release my updated version, if anyone care

"Binary blobs" are only a problem in kernel space. Userspace binary blobs are acceptable. Fence them in with chroot and/or SElinux policies if you're feeling paranoid, and if you find them doing anything suspicious, just strace/ltrace/gdb the bastards. There are plenty of ways to "get an idea what it's doing".

I guess a native binary blob is slightly better than a MS coded binary blob

It's significantly better, actually. Not because it's technically superior (although it may be), but because it can legally be rolled into a commercial version of Linux. Right now, you can't legally distribute a Linux distro with multimedia support (at least not in the U.S.), because they depend either on MS DLLs (obvious copyright problems) or patent-encumbered free implementations (which can't be distributed with the distro for legal reasons).

This makes Linux into a second-rate desktop OS, even if you're willing to pay for it, because it means key features don't work out of the box. There have been exceptions to this from time to time (Xandros, Lindows), but they weren't well accepted by the community, possibly because they tried to leverage their use of proprietary codecs as an advantage over other Linux distros, rather than against Windows -- not a good way to make friends.

A company which wasn't involved in the actual production of a distro, might be in a good position (assuming it dealt with everyone on the same terms) to produce codecs that could be incorporated into (a non-free, pay-per-copy) version of any distro. E.g., someone could take Ubuntu, add the codecs (paying Fluendo, obviously), and sell the result as a package, suitable for pre-installation. I don't think this would violate GPL either, if the codecs were built in a way that didn't require linking or otherwise producing a "derived work."

In short, Fluendo could be in a position to be ESR's "Streaming Penguin." [catb.org] In that paper, he discusses some of the major problems facing Linux as a marketable desktop OS, and the lack of modern multimedia capabilities are a real deal-breaker. In fact, the lack of multimedia capabilities are more of a weakness, than simply being free-as-in-beer is a strength; people are obviously willing to pay for an OS that works, but one that doesn't work out of the box (or works only after fiddling around with some shady instructions involving PLF mirrors) won't fly, even if it's free.

While people here on Slashdot may not regard having to manually install LAME, Xvid, Flash, and the Win32 codecs as a significant problem, it's one of the many reasons why you can't go out and buy a Dell pre-configured with Linux as a home computer. Even if there wasn't Microsoft trying to torpedo it before it gets going, I'm not sure customers would accept anything that didn't work right, right out of the box. Fluendo could, if they play their cards right, be a big benefit to the adoption of Linux.

Xine is probably like MPlayer, and every other linux media player I've heard of that can use windows DLLs for playback - it uses a DLL loader which was forked from avidec at some point, which was itself at some point forked from wine. So while it doesn't use wine directly, and the code's probably mutated along the way to the point where it may no longer resemble the original wine code, it is, in a sense, using wine to load the DLLs.

I'd pay for fully supported video codec's open source or not. I just want my crap to work, preferably in 64bit. The only thing currently keeping me in 32bit is the lack of video codecs and flash in 64bit.
I love open source, but I have no problem with binary blobs. Some of my favorite applications are closed source. I would prefer open source, but I am not going to let my productivity suffer in exchange for my ideals.

2) I guess a native binary blob is slightly better than a MS coded binary blob.... but frankly, it's still just a binary blob. You have no idea what its really doing.

A few things:

a) It is infinitely better than a windows dll because it works (my machine is x86_64. windows blobs won't work there)b) I don't have windows. How can I get windows binary blobs without buying windows or breaking the law?c) True, I don't know what it's really doing, but it comes down to trust. I have personally met spoken to some of the fluendo/gstreamer folks and I trust them a hell of a lot more than some unknown devs at MS who I'll never even know the names of let alone meet and talk to.

> 1) I don't believe (for xine at least) that wine is neccessary for asf (wmv) playback (the windows codec dlls are> required, but used by xine without wine's help)>> 2) I guess a native binary blob is slightly better than a MS coded binary blob.... but frankly, it's still just a> binary blob. You have no idea what its really doing.The MS coded blob is illegal to distribute in the format it usually is (w32 codecs pack) in many (most?) countries. So while this Fluendo deal isn't an ideal solut

Who in there right mind would think that releasing proprietory codecs for exactly the same to linux to do the same thing is in any way a good business plan!? If it was encoding these video formats, there may be some merit (eg: better encoding techniques), but playback!? The only possible advantage is it can be used in non-GPL'd programs.

Agreed, ffmpeg has the ability to decode these same formats, and on alternate arches to boot. The difference is that the use of ffmpeg may not be legal in your jurisdiction due to the lack of patent licenses. This is most likely to matter to, say, broadcasters.Personally, I'm not very excited about paying money for essentially patent licenses. I supposed I'm resigned to being a patent license transgressor rather than monetarily supporting the patent holders. (Of course I also have the option of eschewin

NVidia's lamented product is a binary only driver with a binary only kernel component. A codec is application software. The nvidia software runs on the bare metal, interacting with your machine in god knows what ways. The codecs are fairly self-contained. It's not really compariable.

You are comparing apples and oranges. Wrong comparison.Nvidia is taking flak because the sole reason for the "binary" its own asinine behaviour (same as ATI with the newer Radeon ATI-supplied drivers).

Fluendo intends to provide a service by implementing specs for which the originating party requires a licensing fee.

So the right comparison is not to Nvidia (or ATI for that matter), but to Digium. Digium provides a machine tied (oh what a sacrilege) closed source (oh what a crime) implementation of the g729a

Everyone else is irritated that NVidia's drivers are closed source. I'm just happy advanced native Linux drivers exist. Back when I had a 3D accelerator, ATI's and NVidia's drivers were considered a blessing by most.

Funny how people tend to complain once they learn to expect something.

The three major video players for linux: mplayer, xine and vlc all use the ffmpeg library by default for playing mpeg4 video. Recently, ffmpeg added support for Windows Media 9 (WMV3) as a native codec, so you don't even need the windows binaries for that anymore (although it's probably in "alpha" status).

But ffmpeg can't be distributed legally in all countries. These codecs are for sale for those people who want be legit - usually companies - common crowd will still stick with gstreamer apps/plugins or mplayer/vlc/ffmpeg combo. I see this Fluendo step as very contributing to choice I can make on Linux system - I can say boss that these codecs can be easily installed in public terminal which aim to provide video serices for example. Just buy a license and vola, you are set.

And kudos to ffmpeg team. I use Totem with gstreamer bad/ugly/ffmpeg combo and I can say - hats off to you guys. Quality is very good.

That severely limits the market, doesn't it? It seems like about the only thing you'd be looking at is for mp3 players or embedded devices - and then only for ones that are using codecs developed for x86 or whatever they're making this for.

The FFMPEG devs have always done an excellent job at bringing Free video support to Linux. Thanks to them most video can be played on Linux without propreitary codecs. There is a downside, though: patents. FFMPEG isn't licensed, so it's not legal for distributions to distribute FFMPEG in countries dumb enough to allow software patents (USA, Japan, others?).

The Fluendo stuff could be a good thing if distros would ship with it. Then video would finally work "out of the box". For those like myself who avoid binary blobs and try to only use things that are truely Free will still have the option of using FFMPEG.

And ffmpeg is not perfect. When it comes to WMV files it still has problems. It cannot decode J-frames and some forms of WMA are not supported.

It also tends to be a bit buggy, with various bugs popping in and out depending on exactly when you check out the code. It also does not have regular released versions like other software.

I just recently had to convert several hundred gigabytes of various videos people have uploaded with varying degrees of success. WMV caused problems, and I cannot get 3gp audio files to decode (possibly due to the fact that I'm running 64-bit.

I suppose the market is Linux distributors who can't bundle MPlayer for legal reasons. Can't see anyone buying this directly, though.

They'd probably be legally unable to be as good as MPlayer, (a universal video player, home page [mplayerhq.hu], debs [debian-multimedia.org]), as licensing some codecs will require signing up to agreements to play nicely with DRM. MPlayer is good because there's none of that nonsense: it just works, for every video that I've tried.

That doesn't matter - that's not what this is intended for. It just has to be not much worse than the common alternatives on Windows. Linux has plenty of other advantages that make it a good choice - maintenance alone is far easier for Linux than Windows, for example.

I have much more time to visit with my parents when I'm over now that I've got them switched to Linux. I don't have to keep Windows running anymore. But I couldn't have done it (ther

I don't need player who "just works". I need nice grapgical interface (and no, no mplayer, no gxine/xine, no vlc can provide that, they are totally geekish apps. I am geek, but for videos, I need something more "normal"), I need nice integration with my enviroment, etc. etc.Totem/Rhythmbox provides me that. Yeah, I know, anyone who would say that mplayer isn't for him must be stupid or luser, it is stock answer to my requirements. But it won't change a bit what I said.

as far as interfaces go, i've seen that kmplayer (a kde frontend to mplayer) and totem seem to be fairly decent (though i haven't touched it in a while, i used it back when gstreamer was fairly new and didn't support all that much). now that gstreamer has matured alot more i'm not too suprised about this, and hope that things like this happen much more.

Really... Funny how my wife and 15 year old child are way more capable than you using MplayerGUI. It's easier than Windows Media Player.I strongly suggest you get out of using a computer and specifically linux, it's way to complicated for you if you cant handle mplayer.

Hell you can even get a mozilla/firefox mplayer plugin that makes it so everything on the net plays nicely without effort.

apt get mplayer-mozilla tends to install everything, but I do admit that that is incredibly difficult to do so you can

Of course, MPlayer is also legally unable to be as good as MPlayer. The w32codecs package they create is quite large but given out for free. It seems Fluendo aims to resolve this by making available many of the libraries previously used via w32codecs. As a result, they're probably going to pursue MPlayer on the subject. Many of the codecs are probably freely distributable, and I hope that doesn't change.Of course, there is another reason one might buy this directly: non x86 platforms. Powerbook G4 users fre

Actually, in at least the EU and the UK, and probably the British Commonwealth, software patents are not legally enforcible.

Nor will they ever be. If the law is changed to allow software patents, then it will be recognised that they were never valid before; so any software patent previously but falsely granted in the EU or UK will be recognised as bogus. The holders will have to re-apply for them, but will be blocked by reason of Prior Art and/or obviety (since there will be code out there to do the sa

Rah rah. I like people trying to sell commercial things on Linux. This will only work if they are johnny-on-the-spot when it comes to updates. I would hate my purchased codecs to keep me from updating gstreamer, the kernel, or whatever. In fact, I should not even have to *think* about my purchased codecs when I run a yum, apt-get, or up2date.

I'll just wait here for the Free Software fire-breathing demons of zealotry. It's quite cold right now and my furnace needs a break.

If you have read Christian (Fluendo most visible VP) blog post, they plan to provide upgrades via distribution upgrade/installation system (apt-get, yum, etc.)

How would this work? Does APT or YUM work via authenticated HTTP connections? They'd obviously need some way to keep just anyone from sticking "apt http://fluendo.com/updates [fluendo.com] nonfree" into their sources.list and grabbing their software -- and I don't think their business model is going to fly if they attempt to do shareware.

I'll just wait here for the Free Software fire-breathing demons of zealotry. It's quite cold right now and my furnace needs a break.

The path of the righteous man is beset on all sides by the coding of the closed and the tyranny of proprietary applications. Blessed is he who in the name of 4 Freedoms and good will frees the source through the valley of darkness, for he is truly his brother's bitkeeper and the user of obsolete hardware. And I will strike down upon thee with great vengeance and furious ange

> This will only work if they are johnny-on-the-spot> when it comes to updates.I belive that is why they try to have stabilised API version - gstreamer is close to 1.0 and probably when it is finished the API for plugins will froze so that any new API will not conflict with old (like propertiary codecs) plugins.

But for 90% of the market, whether a codec is proprietary or not is of little consequence. Closed and open work just as well on Windows, and until that changes, that's the way it's going to be. Linux users don't have enough clout to change that, unfortunately.

Hell, I'd settle for every other video I download not requiring a codec I don't have and won't automatically download. And I'm on windows! I think that auto download codec thing for WMP has worked all of one time(s) for me.

Wait a sec.. You mean you want us to abandon the possibility of implementing DRM, allow customers to fairly use our media, remove our ability to exploit the living crap out of our content providers, and fail to benefit the industry types who give us huge sacks of cash money to keep telling our bosses that their proprietary codecs rock everyone's socks six ways?

The most recent Windows Video, RealVideo, and Sorenson video (Used by
QuickTime prior to H.264) are what I might call proprietary in that there is no
public standard. They are likely covered by patents as well. MPEG-4's AVC or
H.264 may be publically documented but is covered by patents which put free
software implementations in the same legal mud as any proprietary codec. On
the audio side, MP3 and AAC are in similar situations: publically available but
patented.

There is no viable alternative. Theora is just too obscure to be useful. There are DirectShow codecs for Theora, but they don't work well, jump over frames, almost always mess up the A/V sync and so on. ffdshow theora is not enough, you need Ogg support too (since Ogg is the container, and theora is the video bitstream). Also, this involves installing codecs in 90% of all cases, since nobody has theora, as previously stated.So. Alternatives? Dirac? Snow? Powerful and very advanced, but a) beta b) even less

Several of the codecs in mention are heavily patended and FFMPEG's legality in many countries is not clear. The codecs from Fluendo, however, have a clear legal status as Fluendo has signed agreements with the patent holders.

That is the major difference between the offerings from Fluendo and FFMPEG.

First of all, look at the Open Sound project. They filled a niche by selling drivers for certain sound cards that had more features compared to the OSS drivers.Second, I think that it is even easier to sell these kinds of things today. They can make a deal with somebody like Novell or Xandros who want to provide their users with a fully functional fully LEGAL linux desktop. This will help them to do that.

I don't see this being so popular with non-commercial distros like Debian because its a different set of

I hate DRM as much as the next person, but this is good news. Acquiring and installing proprietary codecs is a dark art that is major obstacle to wider acceptance of the Linux desktop.

Given some further development, I can see a few opportunities:

distros like Suse and Ubuntu could integrate their package management systems with Fluendo and offer fully legal point and click codec installation for a small (compared with the Windows anti-virus tax) fee

> Acquiring and installing proprietary codecs is a dark art> that is major obstacle to wider acceptance of the Linux desktop.This is BS. Installing multimedia support for decent distro is as easy as:- enabling an additional repository- issuing a command

You can do this either clicking with your mouse or just with terminal. I'll show with terminal since it is more strict, for Fedora:

I agree that this will help with the take-up of Linux, but I don't see how you can equate DRM with proprietary codecs.

Proprietary codecs often have some benefit to end-users in the form of improved quality, improved resolution (not the same thing) and/or improved compression. SVQ (Sorenson video) codecs in Apple Quicktime certainly helped to make that product popular for some of those reasons, at least until it was surpassed by MPEG-4.

DRM is a benefit to nobody, except when it comes to lining the pockets

A lot of people will complain about this, but I think it is good. The more software, of any kind, that comes out on Linux, the better. The more software that eliminates some of the work to get a system up and working, the better. The more shrinkwrapped software for Linux on store shelves, the better. As Linux gets more visibility, and day to day tasks become easier, more people will adopt. This will drive development for Linux. Hopefully some of those adopters, especially the younger ones, will get in

Except that this takes away some of the legitimacy of using the same codecs for free, and gives fewer reasons for media developers/distributors to use open codecs. If you had somewhere you could have paid for it, circumventing the law to get it seems more immoral than if you had to choose between ripping off the codecs and using Windows. Then, once Linux gains a little bit more popularity, media distributors might have started to take into consideration that they can't play wmv files, and if they want those

It gets people in the door, and once people are in the door, its easier to convert them. Also, some people do have issues with breaking the law, whether moral or immoral, and if this was the last hurdle for them (codecs are a big deal for some people), it will let them adopt. Sometimes you have to sacrifice to move forward. Also, there is no restriction on continuing to develop open libraries, and once those are better than the closed versions, people will move to them.

I haven't scrolled to the bottom yet to see if this is redundant, but FFMPEG has recently added WMV9 and VC1 decoders. http://ffmpeg.mplayerhq.hu/ [mplayerhq.hu] It works fine for all of the Legacy content that I have. They also have MPEG/2/4 and a whole bunch of others. The only codec that I seem to be missing is Indeo 5

I see a lot of people confused about why we are releasing these codecs when there are things like the open source ffmpeg codecs etc.Our goal is not to provide the community with codecs which there is absolutly no support for already asthat would be foolish. Our goal is to provide a 100% legal option which I know a lot of companies who have orwant to deploy linux desktops have been looking for. These companies like open source, but they also have policies in placewhich hinders them from deploying solutions which have clear patent issues hanging over them in their country of operations. This is unfortunatlythe case with most multimedia codecs and even though we have spent a lot on resources on Xiph codecs here at Fluendo and are now working with BBCon Dirac there is still some way to go before the need for non-free codecs are gone.

So for those in a situation where they can freely use gst-ffmpeg and similar options, more power to you! For those who the lack of licensed codecshas been a hinderance or problem for adopting Linux (or Solaris) desktops at your company or institution or even private use, then we hope our plugins will be a good solution.

Speaking for myself, I've been using Linux for a while now and, these days, it is the primary OS I use on my home desktop computer. Windows is still there, but for legacy programs that I still need and I switch off the internet whenever I start Windows (it's WinME).

If you can give me a Linux distribution that is supported and comes bundled with legal implementations of all the codecs at a reasonable price point, I'll buy it. Throw in something like Cedega for games or Crossover Office for other apps (if I even need it at this point) so I can get rid of my Windows installation entirely and that would be an ideal solution for me.

Proprietary, non-free applications are going to be essential to getting Linux into the mainstream. Software sellers aren't interested in an OS they can't sell software to run on.

I deal with libraries in my line of work, and I think Linux and libraries are very compatible ideas. Librarians are also sensitive about respecting copyright, and I think codecs are possibly the biggest item slowing down adoption of Linux by librarians. Bravo!

What codecs are these guys going to release that arent:A.Supported by ffmpeg/libavcodec/whatever else through open source implementationsB.Supported already through binaries on linux (such as the RealPlayer binary codec libraries)or C.Not used enough for people to actually care about support

MPEG2 and MPEG4 have LONG been supported by ffmpeg, mplayer, xine, and vlc. As for Windows media, libavcodec in mplayer has supported decoding Windows Media 7 and 8 natively for some time now, and just recently support was added for WMV9 (aka VC-1, the latest Windows Media codec used on HD-DVD and Blu-Ray) using, again, a fully open-source decoder.

Many WMVs I've seen look like shit. It's not the fault of the codec, it's just many idiots feel the need to re-encode videos over and over again. Same problem with Google Video and YouTube. So many things there have been re-encoded so many times all you can really see are blury objects behind the encoding artifacts.