[MPlayer-users] NODAEMON: 2nd try - I still would like to say a few words to the developers...

[D Richard Felker III]

On Mon, Jan 12, 2004 at 01:22:11PM +0100, ThMO wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hello again you all.
> 
> I still would like to say a few words about your standpoint in
> developing mplayer - so if you would be so gentle to read it be=
> fore you're going to give me some well-known "feedback" already
> read.
> 
> I was able to manage to get mplayer v0.50 to work on my older
> system, with all the unneccessary stumble stones there.
> And I can't understand why you're trying to close-out those not
> having the time to permanently "upgrading" the system to the new=
> est versions.

Could you explain how we're "trying to close out" anyone?

> And please, keep in mind that I'm developing soft=
> ware for about 20+ years now, so I do understand some of your cry=
> ings - especially within some "documentation" files in v0.92 .

> FYI, I'm using the following system - everything compiled and
> configured by myself (since 1998):
> · AT board with a PII/350, 128 MB RAM, S3Virge, SCSI only

No problem here -- a good system.

> · linux 2.0.35

This probably has many vulnerabilities.

> · gcc 2.7.2.1
> · libc 5.4.46

This likely has vulnerabilities that could affect suid programs, or
even non-suid ones when inspecting files in untrusted directories.

> · binutils 2.9.1.0.4
> · gas + objdump from binutils 2.14 (for MMX support)
> · XFree 3.3.2.3
> · svgalib 1.4.3
> My system is up to date as neccessary - nothing more and nothing
> less - as I'm *using* my system - and I do have some more hobbies
> instead of installing a newer distribution every five minutes.
> 
> I do understand, for what I've read within the documentation tree
> for v0.90 and v0.92, that it's really cumbersome always reading
> about some "bugs", only present there because the users are using
> a non-gcc two-point-ninetysix  version - but IMHO it's not the right
> thing to blame the users about working against the developers.  Your
> critics are correct in this place, only you should address those who
> are responsible for this pile of shit - the distributors, namely redhat
> in this case.

Could you refrain from ignorance in criticizing us? Back when Redhat
was shipping two point nine six, we got flames from users virtually
_every_ _day_ telling us that their holy Redhat could do no wrong, and
that it must be _our_ fault that MPlayer wouldn't work on their
systems. Thus, _users_ _against_ _developers_ -- because stupid users
insisted on flaming us!! Not the other way around!

> The same goes to the flame war with a jerk like j.parr.
> IMHO this is of no interest to the users...

Maybe, maybe not. You're free to skip that section if it doesn't
interest you.

> I was unable to get v0.92 compiled as the inline assembly instruc=
> tions - namely for the ffmpeg package - is using a `+'-constraint for
> defining the register usage - this older gcc doesn't like that, in=
> stead it would work with a `='-constraint...
> (but I'm not a mmx-assembly guru)
> If it could be rewritten without the "+r" constraints it would clean=
> ly compile even with 2.7.2.1 - the best approach, IMHO, would even
> be to place it in the corresponding `*.S' files...

No, this has been discussed before, and does not work. Different
systems have different conventions for mangling function names (some
add initial _, some don't, etc.) so you have to define your functions
in C or else do nasty hacks to rename them in the .o files.

> The next problem is (and was for v0.50) the non-existent `__extension__'
> keyword - just defining it empty during the configuration phase would
> solve this problem too.
> The same applies to the `__attribute__((__packed__))' stuff for some
> typedef'd types - those attributes are valid within 2.7.2.1 for struct=
> ures, but not for typedef's...

I agree it would be nicer to clean up this stuff so it's not
gcc-specific, although my motivation is an eventual migration away
from gcc to a new compiler that doesn't suck... :)

> I tried to get v0.92 to work - it would have been working without MMX-
> support, but my system is too slow for decoding without MMX - simply
> because v0.50 doesn't handle DivX v5 movies...

There's a lot of other stuff 0.50 won't handle too!

> The SVGA interface (vo_svga.c) was way too slow - and even the version
> within v0.92 doesn't really look fast - I was able to speed it up up
> to 2.5..3 times.

Then feel free to send a patch, but only against latest cvs. It's
probably been greatly changed since 0.50. :)

> Please, try to *not* misunderstand me - you're doing a great deal of
> work with developing mplayer, but maybe you're willing to drop some of
> the stumble stones present in your actual source code, so even users
> with an older system are able to use your software ?

Your computer is NOT an older system. It's about on par with the
system I use for development, and can certainly run modern tools with
no problem.

If you're going to use a 2.7-series gcc, at least use 2.7.2.3. 2.7.2.1
was known to be buggy, IIRC. But if you want to run MPlayer, I think
you really need to install 2.95.3 (in its own isolated directory if
you prefer) and compile with that. 0.50 is way too old to support most
files you'll encounter, and even 0.92 is quickly becoming outdated.
Supporting old versions is a waste of our time. If you really want,
you can fork them and make your own cleaned-up versions of 0.50 on
your own site. :)

Rich