[wizboy11]

*outdated*
Latest version now in svn

[wizboy11]

Since for some reason I can't edit the post (really annoying) I have to reply.

I also used:

Code:

LDFLAGS=-Wl,-O1 -Wl,--sort-common -s"

Can't tell the difference with or without them but those flags are generally safe so I kept them in the file above.

Using CFLAGS in the make line for some reason will break it. But if I add it to the config.mak file it works fine.

Really wish I could edit the above post :p

[Deff]

Looks promising

[wizboy11]

Updated one LDFLAG to this:

Code:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -s"

Really wish I could edit this link into OP.
Fast Mplayer 2 (need WinRAR/7zip to open)

Copy and paste to system/players/mplayer
You'll know it's the right directory since you'll have to overwrite the old files.

Enjoy

Also, I'm stuck on one thing. Whether mfpmath=sse or mfpmath=387 is faster. And I have no real way to test it (AFAIK, anyone with suggestions besides watching a video?).

Anyone wanna test the two? See which one is faster. Everything else between the two is identical. Only difference is mfpmath=sse or mfpmath=387.
Fast Mplayer (mfpmath=387, same as above file)
Fast Mplayer (mfpmath=sse)

My only goal here is to get the most out of a Pentium 3 processor

Thanks.

[gronne]

I'll try it out asap, this is the part of xbmc I am most interested in, so it'll be nice to see if it has improved! Thanks for working on it wiz!

[wizboy11]

I'll try it out asap, this is the part of xbmc I am most interested in, so it'll be nice to see if it has improved! Thanks for working on it wiz!

It's not that much faster. Probably only by a few fps. And I really didn't work on anything but change a -O4 to a -Os in a make file, and add a few other parameters (CFLAGS) to it.

[Gamester17]

Cool, ...but have you done any MD5 checksum tests on the outputs to make sure they are the same with these parameters? I am not sure but I believe that adding "-vo md5" to "XBMC/system/players/mplayer/mplayer.conf" is probably the simplest way to debug check if the MD5 sum on the output are the same? (Maybe you have to dump the output file to the harddrive as well?)

[wizboy11]

Cool, ...but have you done any MD5 checksum tests on the outputs to make sure they are the same with these parameters? I am not sure but I believe that adding "-vo md5" to "XBMC/system/players/mplayer/mplayer.conf" is probably the simplest way to debug check if the MD5 sum on the output are the same? (Maybe you have to dump the output file to the harddrive as well?)

No idea what that is.
Like I said. I'm no programmer. Just a loyal fan I guess.

I don't really see how it could change. The only thing that really changed is -O4 to -Os. I'll try it. Although I'm not sure what I'm doing. Very new to this.
I decided to change it to -Os just to try it. Never thought I'd make it faster.

I'll get back on that md5.

[wizboy11]

Added vo md5 isn't giving me anything. (And I'm not really sure what to look for/do).

Step by step maybe? :p

[Kinslayer]

I tested this using a 720X480 X264 file encoded with the HQ Slow profile, full AC3 audio and packed into an .mkv container. It was also streaming off my network if that makes any difference.

I ran the same sequence of about 30seconds multiple times for each test.

Normal Mplayer = 120-125 dropped frames
Fast Mplayer (378) = 88-92 dropped frames
Fast Mplayer (sse) = 88-90 dropped frames

It may be user perception, but the sse version also seemed to be a bit more consistent dropping frames.

Thanks for this! I hope it gets pulled into the source tree.

-Kinslayer

[spiff]

until somebody can explain why optimizing for size increase the speed...

[elupus]

neat. could you try running the benchmark switch on it? turn on debug log, then add a .conf file with same name as the file you play ie filename.avi.conf in same dir as file.

file should just contain these two lines.
benchmark=1
nosound=1


then look at xbmc logfile after playback, it should give you timings for the playback.

[wizboy11]

until somebody can explain why optimizing for size increase the speed...

No idea why either. Maybe it has to access the HD and RAM less.
I was just fooling around with it. Guess I got lucky?

neat. could you try running the benchmark switch on it? turn on debug log, then add a .conf file with same name as the file you play ie filename.avi.conf in same dir as file.

Thanks.
Finally I have a way to test the mfpmath=sse.

Also, what about that MD5 thing?

[C-Quel]

Unusual but if it does not affect quality every frame gained is a bonus... Kudos.

[wizboy11]

It's benchmark time.
The results are in.
First off, the original mplayer.dll that currently comes with svn was the slowest. Second, I couldn't see the difference between mfpmath=sse or mfpmath=387. They basically tied with each other.

Testing was done with the flags in the OP. Along with following LDFLAGS:

Code:

LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -s"

I did testing on 2 h264 files.

First off -mfpmath=387 (4.91)
H264 File #1:
time1: 65.599
time2: 63.790
time3: 64.630
avg: 64.673

H264 File #2
time1: 58.821
time2: 58.296
time3: 59.913
avg: 59.01

Now, -mfpmath=sse (4.93mb dll)
H264 File #1:
time1: 64.240
time2: 63.794
time3: 63.989
avg: 64.008

H264 File #2:
time1: 60.226
time2: 58.972
time3: 58.673
avg: 59.290

How about that slow(er) original:
H264 File #1:
time1: 64.967
time2: 67.508
time3: 68.027
avg:66.834

H264 File #2:
time1: 61.616
time2: 61.663
time3: 61.386
avg:61.555

Conclusions:
Using -Os gave noticeable speed improvement (not by much, but still every little bit counts on a P3 733mhz processor).

I'm still debating whether mfpmath=sse or mfpmath=387 is faster.
I'll give myself the benefit of the doubt and say the mfpmath=387 is going to be the faster one based on experience.
So that would make this file the current fastest mplayer.dll:
Fast Mplayer (mfpmath=387)

If anyone has experience with Pentium3 processors and knows whether mfpmath=sse is faster or mfpmath=387 is faster, drop in and let me know. I have no idea what kind of floating point processor is on the P3. I only know that 387 is faster on a K8.

Test them both out (few posts back have both files).
Maybe one might be perceived as being faster. I'll just go with that one.

Thanks.