2007-11-05, 23:16
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.
