[LINUX/MAC/WINDOWS] MPlayer porting to XBMC for Linux/Mac/Windows?

The wiki states that mplayer porting is medium priority... Correct me if I'm wrong, but I feel like video playback is the most used aspect of xbmc for most users... mplayer video playback is MUCH better than dvdplayer so I'm wondering if any progress has been made with mplayer?

With close to 500 movies on my smb server, I can throw any of them at mplayer on my current hardware and they all play without a hitch.... but using the same hardware and xbmc I would say only about 3/4 of them play without any problems and cpu usage is always higher with xbmc/linux..

I swear I'm not complaining and I know that it's still very early.. I'm just asking and wondering if the mplayer porting has made any progress...

I totally agree with rrambo. I'd like to see mplayer integration as a high priority.. or at least a workaround to be able to play videos through the mplayer executable. mplayer always plays my videos perfectly (and with much less CPU).

I'm not complaining either.. just so excited to be able to be able to use xbmc full time on my shuttle box!

cheers,
runstop

porting mplayer is low priority because mplayer cannot be used in a proper way on linux due to ld limitations / mplayer requiring all 8 registers - no -fPIC support

Spiff, do you mind explaining further? I guess I don't understand something fully.. Sincy mythtv and geexbox on linux uses mplayer due to it's superior video playback I'm not understanding the limitations of linux mplayer with regards to xbmc...

Thanks...

those use mplayer in slave mode, i.e. they send a window id to mplayer and mplayer handles everything.

that's not xbmc works, nor how we want it to work. we want complete control over our players, cause without it the ui integration would be sucky, and we are left at the mercy of external code not arsing up.

this means that we want to load the player as a .so (a dynamic library). linux handles relocations (i.e. where our base in memory is) by having the base memory adress stored in a register (-fPIC). mplayer has tons of assembly code which uses all registers, hence it cannot be compiled with -fPIC

Now I understand... I see what you're saying and I appreciate the explanation.... I wasn't thinking about how the other programs just call up mplayer and use its controls... integrating mplayer, but not really.... it just appears so...

Thanks again...

First of all, I'm not a developer, so maybe I'm wrong, but... couldn't libvlc do the job?

spiff Wrote:porting mplayer is low priority because mplayer cannot be used in a proper way on linux due to ld limitations / mplayer requiring all 8 registers - no -fPIC support

I don't understand where this is leading to. Does it mean that XBMC Linux will only use DVDplayer to play all videos? Or that, when ported, your version of mplayer will behave the way you want it?

It means we won't put much effort into trying to make mplayer into what we want (for above listed reasons), instead we will extend and improve our "dvdplayer core".

Despite what some people believe, it's still Early Days with the linux port and development is quite slow because it seems like new developers are "shy" (was the kindest word I could think of) to join the effort.

pike Wrote:It means we won't put much effort into trying to make mplayer into what we want (for above listed reasons), instead we will extend and improve our "dvdplayer core".

Ok, I understand. Thanks for clarifying.

Quote:Despite what some people believe, it's still Early Days with the linux port and development is quite slow because it seems like new developers are "shy" (was the kindest word I could think of) to join the effort.

This really saddens me . Unfortunately i don't know any good coder and I'm definitely not one myself.