• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11
Compile faster Mplayer.dll with different parameters
#31
elupus Wrote:i meant the xvidcore lib. that should't be linked in, so i'd be very surprised if that affected the size of mplayer.dll

I replaced xvidcore.dll.a, xvidcore.dll, and xvidcore.a with the new ones I compiled from the latest xvid CVS.

Wait, NVM, for some reason when I re-downloaded the SVN source (since for some reason my other svn links got broken) it seems that it started compiling it slightly smaller every time (it read 4.98mb instead of 4.99mb for some reason). It just happened to be the one time I replaced something and made me think I did something.

Never mind. Smile

I'm trying out a few other optimizations but I don't think I can really get that much more out of it.
Reply
#32
I've finally finished about another hour of testing.

And I'm satisfied with the results. I've tried different combinations of options but I've always found a certain combination that resulted in the fastest mplayer.

I'm still split over the mfpmath= issue but I've decided to go with mfpmath=sse since it seems to provide a more constant result only .2 seconds slower or faster in most cases, so either way it doesn't really matter which one I use.

I'm really tired of this whole mplayer thing right about now :p. But I think I quite thoroughly tested it for speed and I don't think quality or stability was sacrificed in any way, shape, or forum.

I present the latest and greatest:
Fast Mplayer FINAL v1

This is the version that should be integrated into the svn IMO, I guess that the final decision would be up to the developers.

I've included the codecs.conf in case your using a really old build, the mplayer.dll (duh!) and the config.mak file I used with the parameters all zipped up nicely in a 7z. file.

You only need to cop the mplayer.dll and the codecs.conf to system/players/mplayer and overwrite the old ones. The codecs.conf file only really makes a difference if you using a really old build.

Someone should put this in the OP (and yes, I guess I'm still complaining about not editing posts :mad: Angry)

Thanks. Cool
I'm gonna take a nice vacation from testing this sh!t since I'm tired of it right about now. Basically 3 days straight of doing nothing but testing player, thinking about mplayer, and compiling mplayer.

Now I guess I can reap the rewards and watch something for once.

Enjoy Big Grin


*****Re-reads everything since I CAN'T EDIT!!!!!***** Angry
(and I still probably forgot something)
Reply
#33
ultrabrutal Wrote:wizboy11, first; Great work! Now, why doesn't xvid's need speeding up? look at the frame drops on an unlimited (not using plugh's version) xvid at 1280x540. any speed up would result in less dropping.

I was wondering if your experiments can be applied to dvdplayer decoder (and divx codec) also because this one is much faster than mplayer (but still lacks subtitle support) so it's my prefered (or rather required) decoder for hd xvid/divx's


First thing I thought to when I started to read the thread! Big Grin

But still well in Wizboyy11... just goes to show that optomizing can still really help XBMC... so much code nowadays is just bloatware that relies on more and more powerfull hardware... M$ VISTA! LOL!

Top job!
Reply
#34
nice work! .. using this right now with no problems , thank you :]
Reply
#35
i will definatly add this to svn. thanz for the work. i know the feeling of thinking and breathing mplayer, it can get on your nerves Smile
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
#36
@Everyone
Thanks.

That whole xvid thing, since it didn't even use it I didn't even replace it.
Technically, I think every codec that gets compiled (libav, etc..) should get ~5-7% speedup. Nothing big.

Did we ever find out why my compiles kept getting this?
Code:
12:10:23 M: 34058240   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.

Or I guess it doesn't matter Smile
I'm not seeing anything wrong with mplayer.

Cya Cool

And would someone edit the OP with the info thats it's in the svn now, and with the latest package link?
Reply
#37
depends on compiler, i suppose. have never seen it myself. btw what gcc version are you using when compiling?

it shouldn't be an issue anyway since we actually align that stuff before calling into mplayer's process. maybe we don't during init, wich is why it spits out that warning. did you update anything else in your build?
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
#38
elupus Wrote:depends on compiler, i suppose. have never seen it myself. btw what gcc version are you using when compiling?

it shouldn't be an issue anyway since we actually align that stuff before calling into mplayer's process. maybe we don't during init, wich is why it spits out that warning. did you update anything else in your build?

No. I used the latest XBMC SVN build of mplayer. Didn't touch anything (scrapped the whole xvid thing since it didn't even use it).

I'm using Mingw with GCC version 3.4.4 with GNU make 3.79.1. Those are basically thing only versions that will actually compile it without error. In some respects the older GCC versions like 3.4.4 are actually better to use (especially on Win32 platforms).

The message goes away when I compile it without changing anything in the config.mak file. It's probably nothing though. I haven't experience anything wrong with it from the few files I've tried it out with. It claims it's a compiler problem, which it very well might be since the message goes away when I don't touch anything in the config.mak file.

I don't think it's unstable or slow. Probably nothing.
I could start turning off compile options and see if I can find one that causes it but I'd rather just leave mplayer along right now (if it ain't broke don't fix it? Although it is sort of broken, in the sense that we get that message, but it isn't broken since it's visibly faster and stable).

I'll look into it later maybe.
Thanks.
Cya Cool
Reply
#39
well if our fix doesn't work properly, then things will forsure be affected (wma decoding with lavc for example). but i think the message is printed during init, where our fix is not used. will add that there too.
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
#40
just researched, and -Os is not an option as then gcc won't preserve stack alignment properly across function calls. it will break a few codecs, so I can't use that.

what was the results with -O2 instead?
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
#41
elupus Wrote:just researched, and -Os is not an option as then gcc won't preserve stack alignment properly across function calls. it will break a few codecs, so I can't use that.

what was the results with -O2 instead?

Which one of these that -Os disables preservers stack alignment:
Code:
-falign-functions  -falign-jumps  -falign-loops
-falign-labels  -freorder-blocks  -fprefetch-loop-arrays

Then I can compile it with -O2 but using -fno options for the others disabling them right?
Reply
#42
Above doesn't work.
Is there like an optimizations that not using -O2/-O3 would get turned off by that would lead to this?

If I know the right -fxxx options to turn on I can manually turn them on/off to get the smallest possible size.
Reply
#43
Fast Mplayer FINAL v1 instead SVN mplayer.dll, with x264 codec videos at 720x576 resolution:

- Less drops (aprox. 30% of drops)
- The utilization of codecs.conf or svn codecs.conf is indifferent

In my opinion, is important the video cache size. If I set 4096KB instead 256KB the videos have less drops. Why not 16MB cache video?
Reply
#44
If svn mplayer.dll --> 100% drops

Then Fast Mplayer Final V1 --> less than 30% drops
Reply
#45
Mariano Wrote:Fast Mplayer FINAL v1 instead SVN mplayer.dll, with x264 codec videos at 720x576 resolution:

- Less drops (aprox. 30% of drops)
- The utilization of codecs.conf or svn codecs.conf is indifferent

In my opinion, is important the video cache size. If I set 4096KB instead 256KB the videos have less drops. Why not 16MB cache video?

You'll get even more drops. The default cache sizes are the best.
This is from experience. Smile
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 11

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