Helix Player 1.0 Milestone 1 release
Helix Player 1.0 Milestone 1 release
Posted Oct 22, 2003 17:43 UTC (Wed) by TheOneKEA (guest, #615)Parent article: Helix Player 1.0 Milestone 1 release
I don't mean to condemn the hard work of the Helix developers, but after looking at their website, how is this any different from mplayer?
Posted Oct 22, 2003 18:30 UTC (Wed)
by uraeus (guest, #4668)
[Link] (7 responses)
Posted Oct 22, 2003 18:36 UTC (Wed)
by coriordan (guest, #7544)
[Link] (6 responses)
And would there be much point in shipping this helix without the proprietary code? Whenever people mention mplayer, I mention the previous licensing problems, then I get shouted at because they've been fixed. I've never been able to confirm this in any authorative way though. I do know that mplayer isn't in the Debian archives.
Posted Oct 22, 2003 20:51 UTC (Wed)
by flewellyn (subscriber, #5047)
[Link] (4 responses)
Posted Oct 23, 2003 14:31 UTC (Thu)
by elanthis (guest, #6227)
[Link]
Posted Oct 23, 2003 16:02 UTC (Thu)
by torsten (guest, #4137)
[Link] (2 responses)
"I just checked the source tree for mplayer 1.0-pre1 for the LICENSE file, and sure enough, it's the GPL. So I see no reason for any problems."
While mplayer is GPL, most of the AV libraries on which it depends are hacked copies of Windows DLL's, not original works. This player (I believe originally released from Real codebase), contains AV libraries they developed themselves.
Posted Oct 23, 2003 20:20 UTC (Thu)
by jonabbey (guest, #2736)
[Link] (1 responses)
The problem so far as I'm aware is that those codecs are patented, not that mplayer is shipping Windows DLL's.
Posted Oct 26, 2003 7:55 UTC (Sun)
by torsten (guest, #4137)
[Link]
"I don't believe this is correct. Yes, mplayer is capable of using winelib and Windows codec DLL's, but it also uses the ffmpeg library for processing a lot of codecs (Sorensen, etc.)."
You are a little dated. The Linux library loader has long had the ability to dllopen Windows DLL files directly. Those backend libraries that get put in "/usr/local/lib/win32", yup, win32 DLL's. This is not a matter of belief, it is a matter of fact. Check your facts, not your beliefs.
Posted Oct 22, 2003 21:49 UTC (Wed)
by uraeus (guest, #4668)
[Link]
As for licensing. Remember that the GPL contains a clause which revokes the license if the code is covered by a non-free patent etc., which means that Red Hat is legaly barred (even if they got a mpeg license etc.) from distributing GPL'ed multimedia packages like mplayer in the US.
Well one major difference is that people like Red Hat can actually legally ship it. Another major addition is SMIL with is important for the accessibility aware GNOME project.
Difference from mplayer
Would RedHat ship proprietary code with their distro?Difference from mplayer
(I thought they went all Free, like Mandrake, Gentoo, Debian etc)
I just checked the source tree for mplayer 1.0-pre1 for the LICENSE file, and sure enough, it's the GPL. So I see no reason for any problems.
Difference from mplayer
Most of mplayer is illegal in one way or another, tho - plugins are "hacked", and there's been tons of discussions about the nature of a lot of the source (not discussions I've been a part of, so I can't provide specific details).
Difference from mplayer
Difference from mplayer
I don't believe this is correct. Yes, mplayer is capable of using winelib and Windows codec DLL's, but it also uses the ffmpeg library for processing a lot of codecs (Sorensen, etc.).Difference from mplayer
Difference from mplayer
Well I can't really talk for Red Hat, but from my discussions with various people there they have come to the conclusion that they want to ship support for some popular formats with at least their enterprise versions. Never talked about this Real client with them, but I guess it could be one option.Difference from mplayer