Hm, bridging media frameworks is not easy. The curse of always trying to do the weird stuff I guess. I’m trying to wrap the plugins in Xine for GStreamer, so we can make use of their plugins until we get our own. The curse is the state of multimedia libraries in OSS. Some of them don’t release code often enough, some of them don’t even exist as libraries. So all those multimedia projects end up including the code directly with a few minor patches here and there.
So guess what happens when you get crazy enough to bridge two of those frameworks? That’s right, symbol clashes en masse. Now how do I fix those? It doesn’t make it easier that g_module_open for whatever reason insists on using RTLD_GLOBAL no matter what. Oh, wait it doesn’t! Yay for the glib maintainers. Now to convince the GStreamer crew to require glib 2.4 ;)
Oh, and in case you’re wondering why anyone would want to wrap Xine stuff for GStreamer:
- Because it’s there.
- Xine has support for stuff GStreamer doesn’t have support for. My pet peeves are win32 DLL support, lots of input plugins (CD reading, MMS, RT(S)P) and audio outputs for other systems (Solaris, DirectX, …). It’s nice to have at least a stupid solution. Better than none at all.
- I learn a lot about Xine and how it’s done internally. There’s one thing I know already: I like the GStreamer API better.
- GStreamer gets a lot of improvements because it is made capable to cope with weird ideas. Kinda like the obfuscated C contests.
And I’m not having time for anything really serious at the moment anyway because of work so I do light things like writing decoder plugins.