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

[D Richard Felker III]

On Mon, Sep 13, 2004 at 10:52:40PM +0400, Vladimir Mosgalin wrote:
> 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.

there were many versions of 2.96. later versions were fixed, but
earlier versions had WELL-DOCUMENTED bugs that resulted in:
- omission of asm instructions from inline asm
- ICEs
- other code generation errors with pure C code.

if you don't believe me, do the research or install an old redhat and
try it. i'm not going to spend my time looking up the exact version
where it was fixed.

> 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

rotfl?!?! gcc3 is "fast", "compatible", and "usable"!?!? i don't even
think this deserves a response, but i'll give it one:
- gcc3 runs 50% slower or worse than gcc 2.95
- gcc3 generates at best marginally faster code than 2.95, and at
  worst MUCH SLOWER code than 2.95 (10% slower on my k6).
- half the gcc3 releases are full of compiler bugs (ICE & spilled
  register crap).
how something with all these flaws is "usable" is beyond me...

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

umm, we were flamed and abused by fucking lameass redhat users because
they believed the bugs were in our code and not their precious redhat.
that's not cool.

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

no, we'd be the same as 2.95 was at the time, i.e. much faster and
much more compatible.

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

no, my reason for not trying it in a long time is that it sucks:
*downloads xvid file*
*watches xvid file*
*notices mudding artifacts*
*notices that he doesn't see artifacts when encoding comparable
material with lavc at the same bitrate*
*concludes xvid sucks*

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

and it decodes 50% slower...how useless.

(this stat comes from one of the xvid developers, i didn't just make
it up!)

rich