• 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7
[LINUX/MAC/WINDOWS] MPlayer porting to XBMC for Linux/Mac/Windows?
#1
Question 
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...
Reply
#2
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
Reply
#3
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
Reply
#4
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...
Reply
#5
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
Reply
#6
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...
Reply
#7
First of all, I'm not a developer, so maybe I'm wrong, but... couldn't libvlc do the job?
Reply
#8
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?
Reply
#9
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.
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
#10
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 Confused. Unfortunately i don't know any good coder and I'm definitely not one myself.
Reply
#11
I don't mean to spam or troll, but is this an additional point of difficulty which would be avoided with a Win32 port?

Working drivers + mplayer support seems like a step in the right direction compared to the potential difficulties with the current Linux port effort.

I know that this is likely not the best place for this discussion - but I wanted to make my comment in context to this issue.

-- Phob
Reply
#12
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".

A couple of thoughts on trying to use mplayer in a way that doesn't require giving it the window handle directly. Note, it's been 3-4 years since I've done real digging into linking/dynamic linking semantics, so this may just be conjecture, but I think the following are sensible suggestions.

1) What about loading mplayer into a seaprate process and dumping the data back via a shared memory segment or a pipe? This would avoid the whole PIC issue. You might need to dig into mplayer somewhat to make it undrestand an IPC object as an output target, but that sounds much more easy than making the assembly respect PIC.

2) What about liking in the non-PIC mplayer anyways? IIRC, you can actually link non-pic code via a shared object and still be guaranteed correct behavior (could be wrong here...but I think ld.so knows how to handle this). What you trade is efficiency, but assuming you don't load 2 non-PIC segments that conflict cause they map into the same space, I don't think this becomes a "real" issue.

3) If you staticaly link, I think this this all goes away.

4) You could also statically link mplayer, and dynamically load other modules. The possible issue this creates is that you create 2 symbol namespaces, one that's visible during static link, and one that's visible during dynamic link. This can cause multiple copies of the same code (or worse, different version of the same code if your static binary is version skewed from yoru dynamic libraries). However, unless your shared libraries are expecting to resolve to one another, this won't actually cause an additional problems to what you'd have with version skew across .sos.


Ofcourse this is all working on the assumption that there is some intrinsic value to using mplayer over something like gstreamer. I mean, why do people relaly want mplayer? Format compability, efficiency, and reliability usually I think. Thus far, I personally still find mplayer superior to the alternatives, but that superiority doesn't have a very large margin.
Reply
#13
As of now, there are no plans to embed mplayer in the Linux port of XBMC for the simple reason that libavcodec (part of ffmpeg), the library that the "DVD player" uses, pretty much handles most of the common a/v formats and many uncommon ones as well. ffmpeg is very actively maintained and is used by most media players in Linux, including mplayer.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Please read and follow the forum rules.
For troubleshooting and bug reporting, please make sure you read this first.


Image
Reply
#14
terran101 Wrote:Ofcourse this is all working on the assumption that there is some intrinsic value to using mplayer over something like gstreamer
I have no personal experience of GStreamer but I am told that is just a bloated wrapper for FFmpeg (that the FFmpeg developers themselves are not very fond of). Our very own DVDPlayer for XBMC also uses FFmpeg but it is a much cleaner implementation and thus more efficient.


terran101 Wrote:I mean, why do people relaly want mplayer? Format compability, efficiency, and reliability usually I think.
I think the main thing that MPlayer (and also Xine) got that most other video-players for Linux do not have is the ability to load Win32 binary codecs (DLLs), thus making it capable of decoding video encoded with proprietary codecs that FFmpeg does not not yet support, (meaning MPlayer and Xine can be made to support practially any closed-source proprietary codec).

...on the other hand, this capability of using Win32 binary codecs has been a curse on the FFmpeg open source project, since people can already decode their video encoded with proprietary codecs with MPlayer using binary Win32 codecs that removes some on the incentive to reverse engineer those codecs for FFmpeg for an open source alternative, but that is another discussion for another place and another 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.
Reply
#15
[quote=Gamester17]I have no personal experience of GStreamer but I am told that is just a bloated wrapper for FFmpeg (that the FFmpeg developers themselves are not very fond of). Our very own DVDPlayer for XBMC also uses FFmpeg but it is a much cleaner implementation and thus more efficient.

From what I've know gstreamer just has a plugin for ffmpeg that enables it to encode/decode files with it.
One advantage with gstreamer would be that new codecs could be incorpareted easier with gstreamer as the playbin would automaticly choose the best suited codec for the need.
I've tried to create an application that uses gstreamer in opengl with little sucess, with little effort to Smile, although it has been made in theElisa Media Center/ with the Python wrapper. Although one developer, macslow, has made another code for the gstreamer in C that renders in opengl.
macslow's Blog post 1
macslow's Blog post 2
Src

note that I haven't compiled it and tried it Smile

I would think that gstreamer would suit XBMC's need a whole lot better than mplayer but the question remains if gstreamer supports more codecs or is easier to program with.

Also one of XBMC's goals seems to be to run without a desktop enviornemt like KDE or Gnome and I don't know if gstreamer would mess that up. Seriously doubt it though. I think XBMC would benefit from gstreamer but I haven't programed a lot in either ffmpeg or gstreamer.

Over and out.
Reply
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 7

Logout Mark Read Team Forum Stats Members Help
[LINUX/MAC/WINDOWS] MPlayer porting to XBMC for Linux/Mac/Windows?0