• 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 11
Compile faster Mplayer.dll with different parameters
#91
Maybe you can shed a little light on the subject of building it with Microsoft's Visual Studio.

If you can make the solution file compatible and able to compile with Visual Studio .Net 2003 (without SP1) then I should be able to compile it with my Intel C++ compiler.

Unfortunately, the solution file was apparently "made by a higher version of Visual studio" and I can't open it. And the Intel Compiler I have only works for some reason with my 2003 .NET.

Wondering if it would be possible. It would probably greatly increase the speed. (the dll would probably get rather big though, but that probably wouldn't matter).
Reply
#92
you mean mplayer. ah, it doesn't build using it. it's just setup so one can use it for development. it calls on mingw building anyway so don't bother.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#93
elupus Wrote:you mean mplayer. ah, it doesn't build using it. it's just setup so one can use it for development. it calls on mingw building anyway so don't bother.

Well, just curious. I've read that the intel compiler can be noticeably faster sometimes.

I think that my version 1.21 (one in OP) should be safe enough to add to svn now.
We know that h264 is faster. AAC is slightly slower or same speed (depending ao=null?, weird). Xvid is the same speed. mov files use Sorenson video/mp3 audio which really isn't used anymore. Quicktime replaced it with mp4 container and h264/aac. Plus I've never seen a high def mov file that doesn't use h264.

The only things I haven't tested are mp3 or vorbis audio, both of which I've played but haven't benchmarked (and I don't think either would really strain the CPU either way, and I wouldn't be sure how to test them. They're both pretty much 2ch audio at pretty much lower bitrates.)

And if we make changes to it, then you can just update the dll in the svn right?

What are your thoughts.
Do you think it's ready for the svn?

Thanks for all your help Smile
Cya. Cool
Reply
#94
Sorry, Off Topic: Why can't I edit mine posts? Huh
Reply
#95
i'm still missing a mpeg2 benchmark....


Quote:Sorry, Off Topic: Why can't I edit mine posts?

cause some of the mods think that if anybody writes something obscene or trollish, they shouldn't be able to modify their post after. while i don't agree with them, i have no say in the matter since I don't have to deal with trolls on the forum for most of the time.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#96
Benchmark of MPEG-2 VBR, 720x576 at 25 fps:

* a little worse... ;(

* but it's not important, isn't? Smile



MPlayer Original


BENCHMARKs: VC: 149.432s VO: 36.146s A: 0.000s Sys: 5.949s = 191.527s
BENCHMARK%: VC: 78.0215% VO: 18.8724% A: 0.0000% Sys: 3.1062% = 100.0000%


BENCHMARKs: VC: 150.204s VO: 36.283s A: 0.000s Sys: 4.784s = 191.271s
BENCHMARK%: VC: 78.5295% VO: 18.9696% A: 0.0000% Sys: 2.5009% = 100.0000%


BENCHMARKs: VC: 150.233s VO: 36.173s A: 0.000s Sys: 4.957s = 191.362s
BENCHMARK%: VC: 78.5071% VO: 18.9027% A: 0.0000% Sys: 2.5902% = 100.0000%



MPlayer -Os compiled with GCC 3.4.2


BENCHMARKs: VC: 151.191s VO: 35.700s A: 0.000s Sys: 4.618s = 191.509s
BENCHMARK%: VC: 78.9472% VO: 18.6413% A: 0.0000% Sys: 2.4115% = 100.0000%


BENCHMARKs: VC: 151.035s VO: 35.689s A: 0.000s Sys: 4.601s = 191.324s
BENCHMARK%: VC: 78.9418% VO: 18.6536% A: 0.0000% Sys: 2.4046% = 100.0000%


BENCHMARKs: VC: 151.141s VO: 35.604s A: 0.000s Sys: 4.556s = 191.300s
BENCHMARK%: VC: 79.0072% VO: 18.6114% A: 0.0000% Sys: 2.3814% = 100.0000%
Reply
#97
ok, i think the final conclusion is that mplayer should be compiled with -O4, but libavformat/libavcodec/libavutil should be -Os. I hope that won't cause any other issues.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#98
elupus Wrote:ok, i think the final conclusion is that mplayer should be compiled with -O4, but libavformat/libavcodec/libavutil should be -Os. I hope that won't cause any other issues.

Thats great, but how to do that? Smile
I don't think it's really necessary to only compile certain parts with -Os. Not to mention compiling with -O4 (why -O4? I thought it doesn't exist and would just default to -O3?) would turn on -frename-registers which is BAD!!! (it's been taken out in later versions of gcc since it was found to be useless and bad) Personally, I'd compile the rest with -O2 and compile the libavformat/coded/util with -Os if you wanted to take that route.

And how is mpeg2 worse? The total time looks the same to me not to mention you loose system overhead.
The only thing that has truly slowed down was aac when ao=null was on. As far as everything else, I haven't seen it slow down.

So by only doing it on libavformat/codec/util it should speed up x264, and the other videos. But it shouldn't compile aac and the others like it right?

Mariano Wrote:Sorry, Off Topic: Why can't I edit mine posts? Huh

Maybe we shouldn't go there. Wink (read the thread and you'll see why, I whine to much about it too)
Go this in a PM from one of the mods:
http://forum.xbmc.org/showthread.php?tid=22730
Reply
#99
because the VC time went up and the VO time went down. VC is video codec, and VO is video output.

looks the be the same issue as for aac. the codec looses speed, but the vo/ao gains on it. i think O2 for mplayer and Os for libav* would be fine.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
elupus Wrote:because the VC time went up and the VO time went down. VC is video codec, and VO is video output.

looks the be the same issue as for aac. the codec looses speed, but the vo/ao gains on it. i think O2 for mplayer and Os for libav* would be fine.

Ok.
But how would I or anyone else do it?

Would it do something like this:
Code:
OPTFLAGS = -I../libavcodec -I../../libavcodec -Os -march=pentium3 -pipe -fomit-frame-pointer -ffast-math

I haven't tried it yet since Mingw got screwed up on me and I have to reinstall it. But for some reason I don't think it's gonna work.
Reply
FYI - Based upon benchmarking work I've previously done with xbmc's mplayer, I'm fairly certain that the VO / VC measurements are not seperated correctly. Probably a result of the extensive work done on the VO side for the Xbox (pixel shader, etc) missing a call. I'm pretty sure a big chunk of VO time is 'showing up' under VC. (One example if I remember correctly - turn on 'noslices' in mplayer.conf and see what happens to VO / VC values.)

and FWIW, I've done some of my own benchmarking of these builds with respect to mpeg4 (ie xvid avi) decoding, and my tentative conclusion is that the bulk of the (small) gain in that case IS in the video output code (which are probably tight loops that would benefit from being smaller / fitting in cache / reducing code-fetch memory contention).

PS - Y'all might find it interesting to benchmark both HQPS and Overlay output.
Reply
PPS - here's one set of benchmark data that compares
original 2.0.1, 2.0.1 with .conf updates, and 1.21
(This is an extremely demanding 6000 frame HD Xvid clip)
Code:
==============v1.21
-------overlay
20:53:24 M: 21266432   DEBUG:   msg: BENCHMARKs: VC: 194.828s VO:   2.183s A:   3.193s Sys:  50.390s =  250.595s
20:53:24 M: 21266432   DEBUG:   msg: BENCHMARK%: VC: 77.7463% VO:  0.8711% A:  1.2743% Sys: 20.1083% = 100.0000%
20:53:24 M: 21266432   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.94 fps)  drop: 0 (0%)  total: 5998 (23.94 fps)

20:57:40 M: 21245952   DEBUG:   msg: BENCHMARKs: VC: 194.302s VO:   2.156s A:   3.217s Sys:  50.927s =  250.602s
20:57:40 M: 21245952   DEBUG:   msg: BENCHMARK%: VC: 77.5338% VO:  0.8604% A:  1.2839% Sys: 20.3219% = 100.0000%
20:57:40 M: 21245952   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.93 fps)  drop: 0 (0%)  total: 5998 (23.93 fps)

21:02:00 M: 21221376   DEBUG:   msg: BENCHMARKs: VC: 196.116s VO:   2.173s A:   3.222s Sys:  49.080s =  250.591s
21:02:00 M: 21221376   DEBUG:   msg: BENCHMARK%: VC: 78.2615% VO:  0.8673% A:  1.2856% Sys: 19.5856% = 100.0000%
21:02:00 M: 21221376   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.94 fps)  drop: 0 (0%)  total: 5998 (23.94 fps)
-------h.q.p.s.
21:06:30 M: 24387584   DEBUG:   msg: BENCHMARKs: VC: 200.251s VO:   2.025s A:   3.227s Sys:  44.993s =  250.495s
21:06:30 M: 24387584   DEBUG:   msg: BENCHMARK%: VC: 79.9420% VO:  0.8082% A:  1.2883% Sys: 17.9615% = 100.0000%
21:06:30 M: 24387584   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.94 fps)  drop: 0 (0%)  total: 5998 (23.94 fps)

21:10:45 M: 24367104   DEBUG:   msg: BENCHMARKs: VC: 200.664s VO:   2.064s A:   3.192s Sys:  44.671s =  250.591s
21:10:45 M: 24367104   DEBUG:   msg: BENCHMARK%: VC: 80.0764% VO:  0.8236% A:  1.2738% Sys: 17.8262% = 100.0000%
21:10:45 M: 24367104   DEBUG:   msg: BENCHMARKn: disp: 5996 (23.93 fps)  drop: 2 (0%)  total: 5998 (23.94 fps)

21:15:02 M: 24367104   DEBUG:   msg: BENCHMARKs: VC: 201.249s VO:   2.037s A:   3.202s Sys:  44.113s =  250.602s
21:15:02 M: 24367104   DEBUG:   msg: BENCHMARK%: VC: 80.3065% VO:  0.8128% A:  1.2778% Sys: 17.6029% = 100.0000%
21:15:02 M: 24367104   DEBUG:   msg: BENCHMARKn: disp: 5988 (23.89 fps)  drop: 10 (0%)  total: 5998 (23.93 fps)

================2.0.1 + mak mod
---------overlay
21:22:03 M: 21745664   DEBUG:   msg: BENCHMARKs: VC: 198.068s VO:   2.219s A:   3.140s Sys:  47.229s =  250.656s
21:22:03 M: 21745664   DEBUG:   msg: BENCHMARK%: VC: 79.0197% VO:  0.8854% A:  1.2528% Sys: 18.8422% = 100.0000%
21:22:03 M: 21745664   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.93 fps)  drop: 0 (0%)  total: 5998 (23.93 fps)

21:26:22 M: 21696512   DEBUG:   msg: BENCHMARKs: VC: 199.499s VO:   2.226s A:   3.138s Sys:  45.738s =  250.601s
21:26:22 M: 21696512   DEBUG:   msg: BENCHMARK%: VC: 79.6082% VO:  0.8884% A:  1.2522% Sys: 18.2512% = 100.0000%
21:26:22 M: 21696512   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.93 fps)  drop: 0 (0%)  total: 5998 (23.93 fps)
------------h.q.p.s.
21:30:52 M: 24875008   DEBUG:   msg: BENCHMARKs: VC: 205.675s VO:   2.006s A:   3.177s Sys:  39.727s =  250.586s
21:30:52 M: 24875008   DEBUG:   msg: BENCHMARK%: VC: 82.0778% VO:  0.8007% A:  1.2677% Sys: 15.8538% = 100.0000%
21:30:52 M: 24875008   DEBUG:   msg: BENCHMARKn: disp: 5969 (23.82 fps)  drop: 29 (0%)  total: 5998 (23.94 fps)

21:39:30 M: 24850432   DEBUG:   msg: BENCHMARKs: VC: 204.899s VO:   1.993s A:   3.145s Sys:  40.561s =  250.598s
21:39:30 M: 24850432   DEBUG:   msg: BENCHMARK%: VC: 81.7639% VO:  0.7952% A:  1.2550% Sys: 16.1858% = 100.0000%
21:39:30 M: 24850432   DEBUG:   msg: BENCHMARKn: disp: 5969 (23.82 fps)  drop: 29 (0%)  total: 5998 (23.93 fps)

==================2.0.1
----------overlay
21:46:15 M: 20701184   DEBUG:   msg: BENCHMARKs: VC: 200.543s VO:   2.125s A:   3.223s Sys:  44.758s =  250.650s
21:46:15 M: 20701184   DEBUG:   msg: BENCHMARK%: VC: 80.0093% VO:  0.8478% A:  1.2860% Sys: 17.8568% = 100.0000%
21:46:15 M: 20701184   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.93 fps)  drop: 0 (0%)  total: 5998 (23.93 fps)

21:52:02 M: 20660224   DEBUG:   msg: BENCHMARKs: VC: 200.384s VO:   2.216s A:   3.192s Sys:  44.819s =  250.612s
21:52:02 M: 20660224   DEBUG:   msg: BENCHMARK%: VC: 79.9580% VO:  0.8843% A:  1.2737% Sys: 17.8839% = 100.0000%
21:52:02 M: 20660224   DEBUG:   msg: BENCHMARKn: disp: 5998 (23.93 fps)  drop: 0 (0%)  total: 5998 (23.93 fps)
----------h.q.p.s.
22:01:39 M: 23830528   DEBUG:   msg: BENCHMARKs: VC: 204.389s VO:   2.021s A:   3.230s Sys:  40.949s =  250.590s
22:01:39 M: 23830528   DEBUG:   msg: BENCHMARK%: VC: 81.5633% VO:  0.8067% A:  1.2890% Sys: 16.3410% = 100.0000%
22:01:39 M: 23830528   DEBUG:   msg: BENCHMARKn: disp: 5979 (23.86 fps)  drop: 19 (0%)  total: 5998 (23.94 fps)

22:06:18 M: 23805952   DEBUG:   msg: BENCHMARKs: VC: 205.495s VO:   2.019s A:   3.193s Sys:  39.884s =  250.592s
22:06:18 M: 23805952   DEBUG:   msg: BENCHMARK%: VC: 82.0040% VO:  0.8056% A:  1.2744% Sys: 15.9161% = 100.0000%
22:06:18 M: 23805952   DEBUG:   msg: BENCHMARKn: disp: 5962 (23.79 fps)  drop: 36 (0%)  total: 5998 (23.94 fps)
Reply
i've put a test mplayer up on our ftp with mplayer compiled with O2 and libav* with Os, would be interesting with some benchmarks on it in comparison to other builds.

http://www.xboxmediacenter.com/upload/mp...litopt.rar

for those interested, common.mak is only used for libav*, so adding stuff to it's CFLAGS should override what's been set before. it could potentially break some other options thou. (the above .dll isn't tested at all yet)
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
elupus Wrote:i've put a test mplayer up on our ftp with mplayer compiled with O2 and libav* with Os, would be interesting with some benchmarks on it in comparison to other builds.

http://www.xboxmediacenter.com/upload/mp...litopt.rar

for those interested, common.mak is only used for libav*, so adding stuff to it's CFLAGS should override what's been set before. it could potentially break some other options thou. (the above .dll isn't tested at all yet)

Well, I didn't exactly benchmark your version but it does appear to still speed up the h264 file I've been using. Identically as fast, to my eye, as my fast mplayer v1.21.

I also am getting the stack variables not aligned error, "libavcodec has been miscompiled" Sad. It doesn't appear to be causing any trouble though. I'll try recompiling with my system to see if that changes anything.

Also, when I hit "system info" it said that was rev.9001. When the latest version is rev.9619.

Edit:
I've tried compiling it myself too and I still get the stack not aligned error. Thats with GCC 3.4.4
I still think just having the whole compile using -Os is a good idea.
Reply
Update:
Fast mplayer v1.3

Update to original SVN source (rev.9619)
Updated LDFLAGS to use "-Wl,-O1 -Wl,--sort-common -s" (was formerly not using any LDFLAGS, I hope they're getting passed to the compiler, BTW, it's -WL (lower case letter L), people sometimes think it's a 1)

*NOTE*
This version does not use the split optflags as stated above. It is still faster/the same speed then the original mplayer in most codecs, especially h264/AVC.
This version also does not give the stack aligned error (which is good Smile)

Furthermore, I added the cflags, cxxflags and ldflags to the bottom of config.mak (I hope they are all getting passed to the compiler)
Code:
CFLAGS += -march=pentium3
CFLAGS += -mfpmath=387
CFLAGS += -Os
CFLAGS += -pipe
CFLAGS += -fomit-frame-pointer
CFLAGS += -ffast-math

CXXFLAGS += ${CFLAGS}

LDFLAGS += -Wl,-O1
LDFLAGS += -Wl,--sort-common
LDFLAGS += -s
Reply
  • 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 11

Logout Mark Read Team Forum Stats Members Help
Compile faster Mplayer.dll with different parameters0