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

[ThMO]

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.  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
· linux 2.0.35
· gcc 2.7.2.1
· libc 5.4.46
· 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.  The same goes to the flame war with a jerk like j.parr.
IMHO this is of no interest to the users...

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...
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 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...

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.
I'm now able to view a (I guess DivX 4) file called `kb2.divx' with 16pp
through the svga-driver without specifying `-framedrop' and a cpu usage
of 35% for decoding, 24% for displaying and ~3% for the sound.
(the original svga code took about 60% cpu time for displaying)
With mpeg files everything works fine with at most 30% cpu total time.

If you're interested in my diff's - just drop me a note.
(they're small, 9 + 41 kB)

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 ?

Cheers.


CU Tom.
(Thomas M. Ott, Germany)