Compile faster Mplayer.dll with different parameters

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

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.

spiff Wrote: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?

Quote: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?

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

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:

I did testing on 2 h264 files.

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

wizboy11,

can you upload the h.264 files ? I would like to quick test them on a DX1480.

I've added 3 more CFLAGS and made it ~1fps faster. I also went against my better judgment and use mfpmath=sse in it, but it doesn't really make a difference. I'm trusting the GCC guide in that:

Quote:The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit.

But thats not what made it 1fps faster. I added these flags:

I'm not really sure if one might slow it down and then another speed it up but I know it is faster then the previous builds. And it didn't get that much bigger either. This one came in around 4.99mb.

Link:
Fast Mplayer 3

If you want to test using the same files I used I'll upload them for ya. They're packaged in 7z files with the conf file necessary to run the benchmark. Just follow elupus's directions for it:

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

BTW, You can tell I like anime by them (but seriously, it's the only short things I had lying around, both OPs)
h264-File1
h264-file2

I'm done testing today. Whole thing is basically trial and error. So fvck'n annoying but I guess someone has to do it
Thanks.

Hopefully my efforts will pay off one day and this will get intergrated into SVN.

Wizboy11,

Dude!!! 5-7% improvement for free!!! way to go

a) the latest one you compiled is indeed the fastest

b) your benchmarks between runs differ to much. Mine are really much closer of each other! ( did you turn file caching off? file caching affects playback performance in a very negative way and may make you fps vary wildly)

c) a must! definitively a significative improvement over the standard mplayer.dll


d) I ended up not using your files for benchmark as XBMC is capped at 60fps max, and those files played at that framerate most of the time. I used two diferent 720p files, a .mov and a .mkv

e) benchmarks were run with the 9-7-2k7 build from t3ch using the original mplayer.dll and the three builds that you provided, each movie was run twice.

here they are:

Mplayer Orig


oceans_13-tlr2a_720p.mov

BENCHMARKs: VC: 109.048s VO: 17.666s A: 0.000s Sys: 4.697s = 131.410s
BENCHMARK%: VC: 82.9829% VO: 13.4432% A: 0.0000% Sys: 3.5740% = 100.0000%

BENCHMARKs: VC: 108.994s VO: 17.677s A: 0.000s Sys: 4.655s = 131.326s
BENCHMARK%: VC: 82.9949% VO: 13.4602% A: 0.0000% Sys: 3.5448% = 100.0000%

BornToKill_h.264_720p.mkv

BENCHMARKs: VC: 40.955s VO: 4.512s A: 0.000s Sys: 1.136s = 46.603s
BENCHMARK%: VC: 87.8806% VO: 9.6815% A: 0.0000% Sys: 2.4379% = 100.0000%

BENCHMARKs: VC: 40.823s VO: 4.499s A: 0.000s Sys: 1.157s = 46.479s
BENCHMARK%: VC: 87.8316% VO: 9.6802% A: 0.0000% Sys: 2.4883% = 100.0000%


Improvement over original Mplayer.dll: (oceans_13-tlr2a_720p.mov) : 0.00%
Improvement over original Mplayer.dll: (BornToKill_h.264_720p.mkv) : 0.00%


Mplayer fast2 ( i387 )


oceans_13-tlr2a_720p.mov

BENCHMARKs: VC: 102.447s VO: 17.698s A: 0.000s Sys: 4.666s = 124.811s
BENCHMARK%: VC: 82.0818% VO: 14.1799% A: 0.0000% Sys: 3.7383% = 100.0000%

BENCHMARKs: VC: 102.227s VO: 17.635s A: 0.000s Sys: 4.671s = 124.533s
BENCHMARK%: VC: 82.0882% VO: 14.1612% A: 0.0000% Sys: 3.7506% = 100.0000%

BornToKill_h.264_720p.mkv

BENCHMARKs: VC: 37.542s VO: 4.528s A: 0.000s Sys: 1.145s = 43.215s
BENCHMARK%: VC: 86.8724% VO: 10.4774% A: 0.0000% Sys: 2.6502% = 100.0000%

BENCHMARKs: VC: 37.575s VO: 4.512s A: 0.000s Sys: 1.163s = 43.250s
BENCHMARK%: VC: 86.8776% VO: 10.4332% A: 0.0000% Sys: 2.6892% = 100.0000%


Improvement over original Mplayer.dll: (oceans_13-tlr2a_720p.mov) : 5.17%
Improvement over original Mplayer.dll: (BornToKill_h.264_720p.mkv) : 7.02%




Mplayer fpmath ( SSE )


oceans_13-tlr2a_720p.mov

BENCHMARKs: VC: 102.349s VO: 17.681s A: 0.000s Sys: 4.713s = 124.744s
BENCHMARK%: VC: 82.0476% VO: 14.1742% A: 0.0000% Sys: 3.7783% = 100.0000%


BENCHMARKs: VC: 101.291s VO: 17.529s A: 0.000s Sys: 4.709s = 123.529s
BENCHMARK%: VC: 81.9977% VO: 14.1900% A: 0.0000% Sys: 3.8122% = 100.0000%

BornToKill_h.264_720p.mkv

BENCHMARKs: VC: 37.502s VO: 4.528s A: 0.000s Sys: 1.147s = 43.177s
BENCHMARK%: VC: 86.8571% VO: 10.4865% A: 0.0000% Sys: 2.6564% = 100.0000%

BENCHMARKs: VC: 37.541s VO: 4.533s A: 0.000s Sys: 1.110s = 43.184s
BENCHMARK%: VC: 86.9335% VO: 10.4965% A: 0.0000% Sys: 2.5699% = 100.0000%


Improvement over original Mplayer.dll: (oceans_13-tlr2a_720p.mov) : 5.93%
Improvement over original Mplayer.dll: (BornToKill_h.264_720p.mkv) : 7.10%




Mplayer fast3 ( SSE )


oceans_13-tlr2a_720p.mov

BENCHMARKs: VC: 101.430s VO: 17.774s A: 0.000s Sys: 4.676s = 123.880s
BENCHMARK%: VC: 81.8778% VO: 14.3478% A: 0.0000% Sys: 3.7743% = 100.0000%

BENCHMARKs: VC: 101.187s VO: 17.630s A: 0.000s Sys: 4.686s = 123.502s
BENCHMARK%: VC: 81.9313% VO: 14.2747% A: 0.0000% Sys: 3.7940% = 100.0000%

BornToKill_h.264_720p.mkv

BENCHMARKs: VC: 37.565s VO: 4.532s A: 0.000s Sys: 1.167s = 43.264s
BENCHMARK%: VC: 86.8288% VO: 10.4748% A: 0.0000% Sys: 2.6964% = 100.0000%

BENCHMARKs: VC: 37.566s VO: 4.528s A: 0.000s Sys: 1.154s = 43.248s
BENCHMARK%: VC: 86.8609% VO: 10.4697% A: 0.0000% Sys: 2.6694% = 100.0000%


Improvement over original Mplayer.dll: (oceans_13-tlr2a_720p.mov) : 5.95%
Improvement over original Mplayer.dll: (BornToKill_h.264_720p.mkv) : 6.95%

on a sidenote, I get this error on the log, with all mplayer.dll when trying to play the .mov:

DEBUG: msg: Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashes to FFmpeg developers.

Thanks.
Well they probably capped because of the faster processor. For the regular 733mhz processor they stay ~30fps. Lucky you right?

Seems the mfpmath=sse is faster from your benchmarks. I'll just go with that.
Fast Mplayer #3 is the fastest as it would seem.

Also thanks for the tip for disable caching. Didn't do that on mine. I'll try that when I test any new builds I might have (but enough for tonight for me )

BTW if you want to compile these yourself, I believe that these instructions still work:
mplayer compile instructions

Just before you type make, copy and paste the config.mak file from the 7z file and overwrite the old one in the mplayer directory. You can even change the flags on these lines:

I have some redundant stuff in it. I really don't need to be typing -mmmx or -msse since -march already implies these. In fact it probably isn't a good idea . But it doesn't really make a difference. These were the flags I used to compile Fast mplayer #3, which is so far the fastest one. Just make the flags match up in the three lines but I really don't think thats necessary (just to be safe, I wasn't sure what line the compiler would use when).

BTW, would someone please put the link for fast mplayer #3 in the OP?
Keep people up to date ya know? Same with the flags in this post. Have no idea why I can't edit posts. Don't see why that would be a problem but apparently thats what the mods see fit to do.

Thanks