MPlayer OSX Extended (rev5)

[pigoz]

Thank you, works great! can't comment on the CPU usage since I'm using a 64bit mplayer compiled by myself.

Adrian: if you allow to change the mplayer for common users too I will maintain an mplayer.git x86_64 binary distribution for sure.

[Cpuroast]

Originally Posted by Cpuroast

I just tried Rev12-Test2 on Snow Leopard.

It seems that CPU usage during playback nearly doubles in Rev12-Test2 compared to Rev11. Playing back H.264. Haven't tried files encoded in other formats.

This is true for the MT and non-MT options.

I'll stick with Rev11 for now.

Ended up, doing a merge/replace of the mplayer binaries from rev11 into rev12 Test2 and that fixed the high cpu usage and still allowed me to keep the Snow Leopard fixes.

So it's not the front end that is to blame. it's the mplayer binaries from rev12 Test2 that use a lot more cpu power than they did before.

Maybe something is different with the compiling this time, some flag somewhere.

Keep up the great work !!!

[JayBlanc]

Originally Posted by anime_layer

* This is still 32bit. I don't think 64bit is very pressing but I'll look into it. It should also be possible to switch back to the 32bit version for the binary codecs (which aren't 64bit). I think that will need changes to Extended to select the right MPlayer architecture to use.

Just did a test compile using the http://pigoz.wordpress.com/2009/09/0...mplayer-redux/ method and configured to a x86_64 build. Then just did a dropin replacement in your distributed app package.

Works perfectly in embedded window playback! Significant CPU use drop. Being a slightly newer SVN build brings feature improvements as well, such as using the 'D' key to toggle de-interlacing on and off. Biggest improvement for me is it now works fine with Mpeg TS that has aspect ratio changes.

The fun part of this is demonstrating that I can run a x86_64 mplayer binary, with video outputted into the window of the i386 gui app. Much in the same way that QuickTime X drops back to i386 Quick Time 7, you should have no problems running a different arch mplayer binary outputting to the GUI's shared window.

Can I suggest using the same method as with falling back on the multithreaded binary... Allow use of the 64bit decoder, then fall-back on the i386 decoder if it fails (ie, no codec available).

[anime_layer]

Here are some numbers:

CPU: Intel Core2Quad Q9550 2.83GHz
VIDEO:  [H264]  1920x1080  24bpp  23.976 fps

                    (% of decoding time)
single-threaded:
rev12-test2 i386:   172% (cpu extensions disabled)
rev12-test3 i386:   100%
rev12-test3 x86_64:  80%

quad-threaded:
rev12-test3 i386:    49%
rev12-test3 x86_64:  25%

And here you can try it out yourself:
http://mplayerosxext.googlecode.com/...ev12-test3.dmg

Oh, and is there anyone caring for PPC support? The compressed build just got 29MB bigger again...

[Cpuroast]

Originally Posted by anime_layer

Here are some numbers:

CPU: Intel Core2Quad Q9550 2.83GHz
VIDEO:  [H264]  1920x1080  24bpp  23.976 fps

                    (% of decoding time)
single-threaded:
rev12-test2 i386:   172% (cpu extensions disabled)
rev12-test3 i386:   100%
rev12-test3 x86_64:  80%

quad-threaded:
rev12-test3 i386:    49%
rev12-test3 x86_64:  25%

And here you can try it out yourself:
http://mplayerosxext.googlecode.com/...ev12-test3.dmg

Oh, and is there anyone caring for PPC support? The compressed build just got 29MB bigger again...

Test3 doesn't work, libraries referenced from the wrong location.

<Info>: dyld: Library not loaded: /Users/adrian/dev/mplayer/mplayer/usrs/local/lib/libmad.0.dylib

[anime_layer]

*doh* I tried to make sure by checking everything with otool but it turns out only ppc/x86_64 where affected and the command line defaults to i386.

rev12-test4 fixes the issue. No need to update if you're only Intel 32bit.

http://mplayerosxext.googlecode.com/...ev12-test4.dmg

[Eternal Phoenix]

Originally Posted by JayBlanc

Just did a test compile using the http://pigoz.wordpress.com/2009/09/0...mplayer-redux/ method and configured to a x86_64 build. Then just did a dropin replacement in your distributed app package.

Any chance that some generous user could compile a lovely new Snow Leopard-compatible MPlayer build and upload it for those of us who don't know how to code to drop into our OSX Extended packages? Pleases and thank yous as per usual.

[chikorita157]

Originally Posted by Eternal Phoenix

Any chance that some generous user could compile a lovely new Snow Leopard-compatible MPlayer build and upload it for those of us who don't know how to code to drop into our OSX Extended packages? Pleases and thank yous as per usual.

I have already compiled a 64-bit version of Mplayer that is compatible with Snow Leopard a while ago. Here is the link to it. To use it, open the contents of MPlayer OS X Extended > Contents > Resources > External Binaries > mplayer.app (Open Contents) > MacOS and replace the mplayer from the zip to the mplayer.app. Launch MPlayer OS X Extended and go to preferences and change the window to Core Video Separate Window and it should work.

I will upload a new build once I get home since the compiling tools are on my other Macbook Pro.

Whoops... It seems that that build does require a new version of libiconv.2.dylib which I forgot to include. I will update that build with the required libraries when I return. If you still impatient, just do step 1 from this and try it again. It should work afterwards.

[Eternal Phoenix]

Lovely, thanks. According to that article you mentioned, newer builds shouldn't require one to change the video output, so that should fix itself in the new build.

[pigoz]

Originally Posted by Eternal Phoenix

Any chance that some generous user could compile a lovely new Snow Leopard-compatible MPlayer build and upload it for those of us who don't know how to code to drop into our OSX Extended packages? Pleases and thank yous as per usual.

As promised I'm starting to get it moving: http://code.google.com/p/mplayerosx-builds/
It probably misses some audio filters and stuff (like BS2B), as the times comes by I will build it with all the libraries and flags adrian is using.

It is core 2 duo only, 64bit only and snow leopard only.

[Cpuroast]

Originally Posted by pigoz

As promised I'm starting to get it moving: http://code.google.com/p/mplayerosx-builds/
It probably misses some audio filters and stuff (like BS2B), as the times comes by I will build it with all the libraries and flags adrian is using.

It is core 2 duo only, 64bit only and snow leopard only.

Just tried swapping in your mplayer build into Rev12 Test4.

It crashes at startup:

Dyld Error Message:
Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /Applications/MPlayer OSX Extended.app/Contents/MacOS/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

Just thought I'd let you know.

[chikorita157]

Originally Posted by Cpuroast

Just tried swapping in your mplayer build into Rev12 Test4.

It crashes at startup:

Dyld Error Message:
Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /Applications/MPlayer OSX Extended.app/Contents/MacOS/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

Just thought I'd let you know.

This is a result because the MPlayer build uses a newer version of libiconv.2.dylib built by Macports than the one that came with the Rev12 Test4. Installing libiconv from Macports will solve this issue... but the libraries really need to be updated...

[Cpuroast]

Originally Posted by anime_layer

*doh* I tried to make sure by checking everything with otool but it turns out only ppc/x86_64 where affected and the command line defaults to i386.

rev12-test4 fixes the issue. No need to update if you're only Intel 32bit.

http://mplayerosxext.googlecode.com/...ev12-test4.dmg

Hi Adrian,

Rev12 Test4 running in x86-64 on a Core2 Duo in 10.6.1 seems to be behaving normally, good stuff, haven't seen any dramatic reductions in cpu usage compared to rev12 Test2 merged with rev11's mplayer binaries. But I guess it only shows on more intensive 1080p files.

Anyways, I was also curious if it was normal that during playback, mplayer osx extended spawns 2 mplayer processes and not just 1, I know earlier versions would only spawn 1, but Rev11 and up spawn 2.

Keep up the great work!!!

[pigoz]

Originally Posted by Cpuroast

Just tried swapping in your mplayer build into Rev12 Test4.

It crashes at startup:

Dyld Error Message:
Library not loaded: /opt/local/lib/libiconv.2.dylib
Referenced from: /Applications/MPlayer OSX Extended.app/Contents/MacOS/lib/libfontconfig.1.dylib
Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libiconv.2.dylib provides version 7.0.0

Just thought I'd let you know.

thats quite strange... running otool on my binary tells me it should work.
@executable_path/lib/libiconv.2.dylib (compatibility version 8.0.0, current version 8.0.0)

Are you sure you used my version and not chikorita157's one? My version includes in the application bundle all the necessary libraries needed for mplayer to run.
Can someone else confirm it is not working?

[anime_layer]

@pigoz
Neat, thanks for your providing the build!

You also need to change the link paths in the individual libraries, I still see references to /opt/local when calling:
$ otool -L mplayer.app/Contents/MacOS/lib/* | grep /opt/local

I quickly adapted the script I use to change the install names:
http://mplayerosx.sttz.ch/downloads/...tall_names.zip

Running this on the libraries allows me to use your binary:
$ ./mposx_change_install_names mplayer.app/Contents/MacOS

You can find the full script in the Extended SVN under /Scripts/mposx_install which also gathers all necessary libraries automatically but which also contains some Extended-related functionality.

[pigoz]

@adrian: thank you very much; it was the first time using install_name_tool and of course failed at it

[franz2]

Okay guys, I see things improved a lot since my last post here, great. I must unfortunately come with a doubt:

So I am watching a series with linked .mkvs (you know, separate ones for the OP and ED), and while the segment pre-OP plays fine, as soon as the OP starts the sound gets muted, and I have to restart the player and try to skip to after the OP if I want to watch the rest of the episode.

I'm using the rev12-test4 UI with the mplayer-2009-10-13 binary from mplayerosx-builds. (10.6.1, core 2 duo macbook pro)

I was previously using rev11 with a self compiled binary, and while having it play on the same window didn't work, the sound did.

So, anyone knows what's up? (oh just btw, the series is the CoalGirls release of Nogizaka Haruka)

[pigoz]

Do you hear audio if you play only the OP file?

I'll get the files and try to reproduce it. It has probably something to do with FLAC.

EDIT
This is the error message:

Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[flac @ 0x100717800]switching channel layout mid-stream is not supported
[flac @ 0x100717800]decode_frame() failed

Either the files use different channel layouts, or mplayer with linking segments doesn't work well with FLAC; from what I have been told on irc FLAC has only one channel configuration possible for each number of channels (in our case its both 2), so i would exclude the possibility of a problem in the files.

EDIT2
I tried Kovensky's mplayer build for Windows and it has the same problem. At least its not my fail this time.

EDIT3
It was fixed by the mplayer dev, a patch will be out tomorrow probably.

EDIT4
mplayer-2009-10-20 on google code fixes the problem

[LordMelkor]

Originally Posted by anime_layer

Well, sorry for wanting to have something to eat and therefore prioritizing projects with a possible income.

Respect.

The only reason I asked was cuz you hadn't made a post in the thread in over 3.5 months.

[franz2]

Originally Posted by pigoz

EDIT4
mplayer-2009-10-20 on google code fixes the problem

Perfect! Just tried it and it worked great.