[wizboy11]

Oh yea.
And I fixed the "Compiler did not align stack variables."

Don't ask me how either.
Reverted to GCC 3.4.2, and only changed -O4 to -Os. Didn't change anything else and it worked.

I'll post the dll after I add the other options and see if it still works

[wizboy11]

I think I've tracked down the problem.

-mfpmath=sse seems to throw it off and cause the message about stack variables not aligning.

If I don't use it, I don't get the error. But I can still use -Os. So, elupus, it seems that -Os doesn't throw it off.

I think a few other options might have thrown it off too, I'm testing now.

[wizboy11]

Alright, lets try this one again.

This build should have fixed the "stack variables not aligned" problem.
I have seriously reduced the amount of flags used to were the only real difference is -Os instead of -O4.

I'm trying to keep it simple since every advanced one I use seems to break it. The speed difference was minimal with the extra flags anyway and I've also found that -mfpmath=387 is in fact faster then sse (it's amazing how things change over time, one day with this, another day with that).

Here ya go:
Fast Mplayer v1.1

Included are the config.mak file I used to make it, mplayer.dll, and codecs.conf (only really needed if you using a really old build were the new mplayer wasn't included in the svn (maybe, 3-4 months+ ago?).
I've also ditched the FINAL thing as it's pointless. There never really is a FINAL with these things. This is version 1.1.

Now I think it's safe to say, THIS is the one that should be in the svn.
*cross fingers*
Try it and see if you get the stack variable problem. You shouldn't (since I didn't and all Xbox's are virtually the same).

Thanks.
Cya

[elupus]

i expected it to be -mpreferred-stack-boundary wich is set lower when using -Os, but maybe gcc gets it right anyway. please recheck after a few reboots too.

technically everything (or atleast most) performace critical stuff in lavc is hand written assembly, thus optimizing the rest for size could really make sence.

could you test one thing more? add -mpreferred-stack-boundary=4 with the -Os and see what that has for effect.

<edit> just noticed you already had that in your previous version </edit>

[wizboy11]

i expected it to be -mpreferred-stack-boundary wich is set lower when using -Os, but maybe gcc gets it right anyway. please recheck after a few reboots too.

technically everything (or atleast most) performace critical stuff in lavc is hand written assembly, thus optimizing the rest for size could really make sence.

could you test one thing more? add -mpreferred-stack-boundary=4 with the -Os and see what that has for effect.

<edit> just noticed you already had that in your previous version </edit>

I think several options made it break. mfpmath=sse being one of them. I'll try it with the stack boundary=4 just for fun (trying to keep things simple :p).

I also noticed that you updated the svn to call something that might help fix my message warning. I'll try building XBMC with the latest source, the try my different mplayer builds, but just to be safe I think we should use the one that doesn't give me the error without your fix (version 1.1)

I've been using a fairly old version of the svn to test these (rev. 9424, Jun. 24 ish? compiled myself with the build.LTCG.bat file). Not that old though.

Before I update to the one that has your fix in it, I'll try out the one with stack boundary=4 on the older one to see if that would cause it.

Cya

[wizboy11]

Setting stack boundary=4 does in fact break it.

I'll try the new build to see if your fix worked.

I still think though, to be on the safe side (for now at least) to use the mplayer version that doesn't give me the error. Which would still be the same one from a few posts up (version 1.1).

Fast Mplayer v1.1

Cya

[wizboy11]

Just finished building and installing the latest build of XBMC.
When I opened up that log file I saw those index headers you were talking about.

please recheck after a few reboots too.

Yea, I'm still not getting that message. So I guess thats a good thing .
I haven't tried any of my older builds that use to give me the message with the new build of XBMC. I'd rather keep the build parameters simple as possible and stick with v1.1 for now.

Now the only thing left really (for playback) is full ssa/ass sub support.

[Mariano]

SVN-XBMC revision 9561 with "fast" mplayer.dll (version 1.0 or 1.1) and a x264 video 720x576 resolution ---> much better, nearly perfection (better with audio ac3 or mp3 than he-aac, obviously) --> few drops!!! and nearly perfect fps (25 fps).

Please, tell me a video for tested it.

[wizboy11]

Alright (I seem to start every post with "alright" don't I )

Lets try this again (for the fourth time I think).
And I'm almost sure this is the one for the SVN.

Check it:
Fast(er) Mplayer v1.21
(*note* version 1.2 doesn't exist, well it did, but now it doesn't )

Included (as always) is mplayer.dll, codecs.conf (only matters if your using a build older then ~month), and the config.mak file I used to make it (only matters if your a developer/want to build this thing). Should be a good 5-7% faster with less dropped frames on h264/AVC/mpeg4-part10 files (good for HD? , maybe not that much faster... but try it anyway)

What I did with this version (v1.21):
Recompiled with GCC 3.4.4, removed all LDFLAGS (slowed it down) and fixed the version from "unknown" to r9301 when you hit system info as that was the last rev. of the mplayer folder.

I've checked to make sure the message about stack variables not aligning does NOT appear (which is good, made me rollback my XBMC version ) which would make this backwards compatible with all the older builds of XBMC if the stack variables had become a problem. But just to be safe, I'd update your XBMC build to at least 9554 to address this issue so that you know for absolutely sure that those dam stack variables stay in their place (but you should be safe with this build of mplayer)

Cya

[elupus]

okey, just to recap. you said if you specify prefer-stack-alignment the issue crops up?? christ that sound like a gcc bug to me.

anyway, we have another "problem", even if this does speed up h264 decoding, it can very well slow down other stuff alot. se we kinda need testing on xvid/divx,mov,aac,mpeg2... before being able to put this in svn.

i'd be much happier if the change was from O3 to O2, but you say that doesn't give the same boost, soo.

if you feel like playing with something different, you can have a go at building the ffmpeg libs for dvdplayer, and see if you can get the same boost there. the source is in a rar in docs repository.

[wizboy11]

okey, just to recap. you said if you specify prefer-stack-alignment the issue crops up?? christ that sound like a gcc bug to me.

anyway, we have another "problem", even if this does speed up h264 decoding, it can very well slow down other stuff alot. se we kinda need testing on xvid/divx,mov,aac,mpeg2... before being able to put this in svn.

i'd be much happier if the change was from O3 to O2, but you say that doesn't give the same boost, soo.

if you feel like playing with something different, you can have a go at building the ffmpeg libs for dvdplayer, and see if you can get the same boost there. the source is in a rar in docs repository.

You mean prefer-stack-boundary (not alignment, prefer-stack-alignment doesn't exist)

I'll encode a few xvid movies at a high resolution then test them. Not sure how I'm gonna test an audio file, doesn't paplayer do that? Same with mpeg2, doesn't dvdplayer handle that?

I'll try it out on every file type I can imagine.

And technically, all -Os is that it IS -O2 with a few things disabled. IIRC, it doesn't touch prefer-stack-boundary or anything like that, although I'm not really an expert here.

[wizboy11]

And -O2 does give a speed up, it's just not as great.

christ that sound like a gcc bug to me.

I could try it again with gcc 3.4.2?

Unless you want to help me make it compatible with the newer GCC's like 4.2.0 since every version past 3.4.4 seems to break it. Same goes for newer versions of GNU make.

[wizboy11]

Having computer trouble right now.
Also, I have yet to test the xvid files (and others) because of this. Looks like I'm gonna have to reinsatll windows since nothing I'm doing seems to be fixing the problem (virtualdubmod keeps crashing along with avisynth).

So I can't test those files right now.
But when I can you want me to test what kind of files?
So far I have/going to test:
-h264/AVC files (already proven faster)
-xvid (gonna have to wait for these)
-mov (container, really sorsen video with mp3 audio)
-aac audio (not sure, can I disable video like I did audio?)

Anything else?
I can't see any of them being slower. Most are decoded using the same decoder as h264 right? (libav?)

Anyone willing to test some xvid files? I'm gonna have to reinstall windows so I'll be down probably till tomorrow sometime. (then I have to do something else later in the day into sunday morning) so I'll truly be back probably around sunday afternoon. I got real world stuff to do

Also, what version of GCC compiler do you want me to use?

if you feel like playing with something different, you can have a go at building the ffmpeg libs for dvdplayer, and see if you can get the same boost there. the source is in a rar in docs repository.

What am I, some special complier person? :p
For some reason those libs don't want to compile for me (i.e. it's not as straight forward as compiling mplayer and I'm not really that experienced with this stuff, although I've learn so so so much thus far).

Thanks
Cya

[wizboy11]

Fixed computer trouble without having to reinstall windows (yay).

Also did some testing on xvid files.
Used same method as h264/AVC files.

Something I noticed with the faster mplayer is that although it really isn't "faster" with xvid, it appears a little smoother during playback. At least thats my visual interpretation of it.

Benchmarks:

Code:

Fast Mplayer:
78.644s
79.405s

Original Mplayer:
79.126s
79.422s

Not as much of a difference as h264 but there still is a slight difference in favor of the faster mplayer (and it did appear "smoother" although thats just from watching it like one time). I think xvid just won't speed up or slow down really. The benchmarks are gonna go either way each time. However, the faster mplayer did manage to hit 78 seconds and the original didn't, although a number of things could have caused that but I tried to isolate mplayer during these tests.

Furthermore, neither version gave me a "not aligned" error.

Anything else you want me to test? (I don't have any HD mov files, and if they were mp4 then they'd just be h264+aac again).

Also, if you think it is a compiler error, which version of GCC should I be compiling this with?

Thanks
Cya

[Mariano]

Fast Player 1.21 and a compilation of mplayer.dll realized for myself (wizboy11's config.mak) in comparation with mplayer.dll original:

- mkv file with video x264 (cabac and deblocking) at 720x576 resolution --> less drops (few drops with ac3 and mp3 audio, more drops with he-aac audio). If change -Os to -O2 in config.mak then --> more drops (better -Os for me).

- avi file with video XviD 1.1.3 (quarter pixel, global motion compensation, and b-vops) and audio ac3 at 720x576 resolution --> practically 0 drops.

- all my collection of films in hdd (almost in xvid format) run perfect (but they haven't big resolutions...).

P.D.: I'm not a user that needs big resolutions (normal TV ).

P.D.: I will try compile the mplayer.dll original changing -O4 to -Os .