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

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

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.

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.

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.

[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 , 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

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.

My take on this:
1. ffmpeg which is used by dvdplayer is part of mplayer, so in fact one can say that we use portions of mplayer.
2. As spiff noted mplayer is not embeddable. spawning another process and integrating with it might be possible but will require major effort. If someone wants to step and do it -- welcome.
3. Some parts of mplayer, mainly around streaming content, is better than XBMC but we are continuously improving our code and I think most of the functionality is there already.

If there's anything CONCRETE that's missing in dvdplayer/paplayer, I'd love to hear about it.

-Yuval

Features aren't an issue; xbmc plays pretty much everything mplayer does. Performance is, though. Mplayer and totem(xine) take up ~12% CPU speed playing a simple 480i xvid, while XBMC consumes 25-50%. Playing a 720p xvid, mplayer uses 15-20% of one CPU at 1.6Ghz. XBMC takes up 40% of one CPU and 60% of the other (still at 1.6Ghz).

I need to get some 1080p for further performance testing, since I can't even generate enough load to get my cpufreq up to the max of 3Ghz, but it's pretty clear that performance is far lower in XBMC. Now I'm not using those CPUs for anything in particular; this is a dedicated XBMC machine. But it does limit the potential users of the software.

let me guess
no gl 2.0 -> software csc -> cpu pays.
xine/mplayer runs using xv output - hardware csc -> cpu happier
both mplayer and xine are basically just wrappers for ffmpeg decoding wise.

you shouldn't go around judging things you (obviously) do not understand

You are grumpy!

I have a nv 7150 running the binary drivers, it supports opengl 2.1.2. I get rougly 2100fps in glxgears.

well, then something is wrong with your drivers. / configuration, cause what you say really makes no sense. perhaps there can be slight differences, but they should be SLIGHT (as a reference; dvdplayer is slightly more efficient than mplayer on xbox due to a slightly less stupid architecture) oh, and glxgears performance is of no concern - the screen in fullscreen consist of a whopping two trigons / one quad. shaders are what matters

from what little i can find from google it does seem like the hw should support what's needed (PS3.0)

and as for me being grumpy, thats just the eye of the beholder. as far as i'm concerned i'm just being blunt.