[MPlayer-users] rant

[Arpi]

Hi,

> I doubt you will, because mine would allow distribution of binaries:-)
:)

> > yes. Because we DO NOT WANT to see any binaries distributed. LGB described
> > in details why (either it's broken/incompatible or compiled to 386 with very
> > minimal feature list so mplayer looks like a shit proggy)
> 
> I understand and accept that concern, although I do not think it is
> valid. Instead of forbidding distribution of binaries you could
> recommend distributions to create packages optimized for different
> processors. I know that Debian would allow a i686 package of mplayer for
> an example, and I am pretty sure other distributions would too. That
> still won't make use of all of mplayers potential, but it makes mplayer
> available to a much bigger audience (those who can't compile binaries
> themselves).
CPU is one thing. Btw 386 and i686 is only 2 of about 10 possible cpu.
There are X11, SDL and other library dependencies. It compiles different for
no X, X 3.3.x and X 4.x versions. Every release of SDL ahs its unique bug
what mplayer workarounds, but at compiletime. And i can continue.
In short: MPLAYER IS NOT READY FOR PACKAGING. Is it clear now?

You can make source package, they are not forbidden. Same stay for redhat
fans, just make srpm or whatever it's called.

> Lets take xine and vlc as examples of programs which are both in Debian.
The why do you need another player?

> I have not heard people complaining about how "shitty" these programs
> are based on how slow they got when they went into Debian.
No. Instead they use mplayer and tell us how fast mplayer is compared to
xine and vlc... btw they both have runtime cpu detection. mplayer don't
have.

Please. Forget mplayer binaries now. Make source packages or do nothing,
just wait until we finish modularizatin of libao2/libvo2 and add runtime
cpu detection.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu