[MPlayer-users] MPlayer-1.0pre4 bug with divx4 multipass filter

[Vladimir Mosgalin]

On Mon, 13 Sep 2004, D Richard Felker III wrote:

DRFI>> Ever heard that rpm
DRFI>> is used in almost every linux distro?
DRFI>Only about 1/3 of them. The other 2/3 use debs or source.

Well, my option is that except the majority, the small extra uses deb,
and the ones that don't have package manager don't deserve the right to
be called real distributions (excluding live-CDs, LRP and such).
BUT, I don't want to discuss this topic. At all. We both know that it
will lead to nowhere.

DRFI>ARRRRRGGGG!!! Yes!! Look at all the history of gcc bugs affecting
DRFI>MPlayer. Not a single one of them was MPlayer's fault! All were
DRFI>compiler bugs, plain and simple, and they occurred most commonly with
DRFI>Redhat...

All I can say that I started using mplayer in the times of 2.96 and I
never had a single problem with it, except that stupid configure flag.

And AFAIK source of mplayer from distribution (they had some license
problems with distributing binaries about that time, so only srpm was
available) had no problems with it too.

Well, if someone used rh 7.0 (or even 7.1), or used 7.2/7.3 and forgot
to download & install critical updates, it was their problem. Redhat's
actions weren't good, they made guinea pigs out of their users, but for
some reason all the clever people around me had no problems with it.
They always knew that x.0 redhat distros can be like that, and often
they are.

DRFI>> I can believe that some kernel or glibc patches, preloading etc can
DRFI>> result in problems with "unsteady" code, such as win32 loader, but in
DRFI>> lavc under such specific conditions?
DRFI>Yes. A bad compiler will generate WRONG instructions for C code (or in
DRFI>the case of the famous gcc two point nine six, it will randomly omit
DRFI>some of your asm instructions in inline asm ;).

The only reason we all have usable, fast and compatible gcc 3.x right
now is because redhat was experimenting with 2.96. They forced people to
use it and got enormous amount of bugreports this way. People were hurt;
but who asked them to use redhat, especially unstable version in the
first place? But thanks to that, gcc3 wasn't delayed for another several
years. It really IS working. Otherwise, right now it would be the same
as 2.96 was that time.

DRFI>> OK. You can get one yourself, by encoding any file with xvid; I'll post
DRFI>> options that will lead to this when encoding the file I'll upload, to be
DRFI>> sure.
DRFI>I'd like a file I can just play better. I don't feel like compiling
DRFI>latest xvid and recompiling MPlayer with (useless to me) xvid support.

Lol. So the real reason you are hating xvid is that you haven't tried it
for a long time. There is nothing wrong with it, it's usual human habit.
I used to think that lavc is better too, before I tried xvid for real
and it cured all my problems. But if you want to take on that bet, you
must force yourself to download xvid 1.0.2 and recompile mplayer.
Actually, it's even easier than to compile mplayer with lavc (not to
mention faster).

-- 

Vladimir