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

[Vladimir Mosgalin]

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

DRFI>- omission of asm instructions from inline asm
DRFI>- ICEs
DRFI>- other code generation errors with pure C code.
DRFI>if you don't believe me, do the research or install an old redhat and  
DRFI>try it. i'm not going to spend my time looking up the exact version
DRFI>where it was fixed.

I do believe you. But I was talking about completely difference issue.
There were enough smart people who knew about this problems even before
mplayer's troubles with 2. 96; just because they knew that x.0 redhat
versions are always overflowing with all kinds of problems. They made
clever decisions, told people to do the same and had very little
problems both with compiler and such. I guess that by the time redhat
started to use 2. 96 to compile kernel instead of kgcc (old egcs port),
it happened in 7.2 or 7.3, I guess, gcc 2. 96 was stable enough.

DRFI>> The only reason we all have usable, fast and compatible gcc 3.x right
DRFI>
DRFI>rotfl?!?! gcc3 is "fast", "compatible", and "usable"!?!? i don't even
DRFI>think this deserves a response, but i'll give it one:
DRFI>- gcc3 runs 50% slower or worse than gcc 2.95 

Slower, yes. Worse, no. It supports much more features.

DRFI>- gcc3 generates at best marginally faster code than 2.95, and at  
DRFI>  worst MUCH SLOWER code than 2.95 (10% slower on my k6).

I can't confirm this. On my p166mmx, gcc 3.1 was faster than 2. 96,   
which was faster than 2.95. On my current system.. well, I can't really
test, I have only 3.3 & 3.2 versions installed, but gcc 2.95 wasn't even
supporting sse optimizations.. And it sure never heard of athlon cpus.

DRFI>- half the gcc3 releases are full of compiler bugs (ICE & spilled
DRFI>  register crap).

gcc3 has bugs, but for some reasons I don't remember that I ever
suffered from them. Even 3.2, which was considered buggy by mplayer
developers, never had the any problems on my system - because the bugs
were fixed in my distro.  That's what they exist for, to fix numerous
bugs in vanilla gcc/kernel/etc...

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

I feel sorry for you, but you could try to force them to flame redhat's
bugzilla instead.

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

First time I recompiled mplayer with new compiler, it became faster. I
First time I recompiled mplayer with new compiler, it became faster. I
wasn't expecting this, but it really became 5-10% faster.

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

Aha! That is incorrect too. Because in my encodings, I never seen
mudding on high bitrate. At least, I never noticed it.
You know that lavc won't create such artifacts at the same bitrate; but
have you really checked if xvid _will_ create them with the right
settings? Or if it does, that they won't disappear when you slightly
increase bitrate?

DRFI>> I used to think that lavc is better too, before I tried xvid for
DRFI>> real and it cured all my problems. But if you want to take on
DRFI>> that bet, you must force yourself to download xvid 1.0.2 and
DRFI>> recompile mplayer.  Actually, it's even easier than to compile
DRFI>> mplayer with lavc (not to mention faster).
DRFI>and it decodes 50% slower...how useless.

Useless for capture, but who cares if it gives 20% better quality for
dvd rips?

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

Actually, I can't agree with you. With a lot of quality-improving
paramters, lavc is about as slow as xvid in the same situation. Lavc is
only much faster with default settings. For some reason, turning extra 
quality, more intensive motion search, trellis etc on xvid doesn't
result in major performance hit, like it happens with lavc. So lavc is
much faster only for tv captures, when you care more about speed.
For hq dvd rips, they both perform about 10-13 fps on my system.


-- 

Vladimir