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

[Vladimir Mosgalin]

On Wed, 15 Sep 2004, D Richard Felker III wrote:

DRFI>> Slower, yes. Worse, no. It supports much more features.
DRFI>"features" like c++ variable declarations... :(

I don't like c++ too, but the world must go round and gcc must improve
in different areas. A long time ago it was the first public available
real c++ compiler, not just c++->c preprocessor like others, and it
would be a shame if c++ support will become too outdated.

DRFI>> I can't confirm this. On my p166mmx, gcc 3.1 was faster than 2. 96,   
DRFI>> which was faster than 2.95. On my current system.. well, I can't really
DRFI>> test, I have only 3.3 & 3.2 versions installed, but gcc 2.95 wasn't even
DRFI>> supporting sse optimizations..
DRFI>sse optimizations for what? they're basically useless. all they
DRFI>affect is the use of floats in c code, which no one sane would use
DRFI>in performance code anyway...

Who knows? Better than having sse only through inline asm.

DRFI>> gcc3 has bugs, but for some reasons I don't remember that I ever
DRFI>> suffered from them. Even 3.2, which was considered buggy by mplayer
DRFI>> developers, never had the any problems on my system - because the bugs
DRFI>> were fixed in my distro.
DRFI>i really doubt that..

For example, gcc 3.2.2 had problems with mplayer, when compiling faad.
gcc 3.2.2 from redhat had no such problems.

DRFI>> That's what they exist for, to fix numerous bugs in vanilla
DRFI>> gcc/kernel/etc...
DRFI>this is absurd... i understand that this is what it's come to, but

I fully agree to you, but just as you, there is not a thing I can do
about it. To save time, I can only use distros and hope that at least
part of the bugs I can encounter in vanilla soft will be fixed there.
Also, answering to bugzilla requests is part of their work, so they
often do this faster than original developers.

DRFI>> First time I recompiled mplayer with new compiler, it became faster. I
DRFI>> wasn't expecting this, but it really became 5-10% faster.
DRFI>perhaps we should profile which functions were improved and rewrite
DRFI>them in asm, if there's really any c code that can make a 5-10%
DRFI>difference to performance... ideally less than 1% of the cpu time
DRFI>should be spent in the c code.

I was thinking that possibly code size optimizations made this effect.
Or xfree (video drivers) optimizations. 

DRFI>> DRFI>and it decodes 50% slower...how useless.
DRFI>> Useless for capture, but who cares if it gives 20% better quality for
DRFI>> dvd rips?
DRFI>i said decodes. not talking about encoding. i agree performance is
DRFI>irrelevant for encoding.

Yes, sorry. Decoding with xvid sucks, but right now it is the only way
to play some videos.

-- 

Vladimir