Some time ago I announced that we would be working on a GStreamer backend for Phonon. This work is still ongoing, but we have now put the code into the GStreamer CVS repository. The code is still early stage, but at least those interested can now follow the code as it progresses. One thing people will notice is that the current code is still all C which I guess most people would find strange for something meant to be used with Phonon. Well the idea is to provide the Phonon components with both a C and a C++ API. So the current code is meant to both be usable from C and also be easily used to power the GStreamer backend for Phonon. We decided on this approach as we found that since a lot of the work on implementing a GStreamer backend for Phonon was actually about writing some high-level GStreamer components and at that point we came to the conclusion that offering people to use them with a C API in addition to the official Phonon C++ API made quite a lot of sense. The code and design so far have been done by Wim Taymans, but in order to get more focus on the development from here on we will have David Gerber take over from here and work exclusivly on this for a the next months.
GStreamer for Mac OSX and Windows
Those following GStreamer CVS will have noticed that there has been quite a few commits recently for audio and video output plugins for Windows and Mac OSX. This is not a coincidence as we are currently working on a project to ensure that GStreamer works perfectly on these operating systems. The Windows audiosink and videosink should already be in working order and the MacOS X audio sink also works fine. We still have some work needed on the MacOS X video sink, but we hope to have that done by the end of the Month. With these plugins in place writing a cross platform application with GStreamer should be very easy so I suggest anyone working on crossplatform development take a look at the plugins and try them out on their own systems.
Elisa priorities
I know a lot of you are waiting for us to add PVR support into Elisa. This task is making its way quickly up our todo list, but one thing we are going to try to tackle first is how we handle large media collections. Anyone who has ever run Elisa will notice that while it looks very nice the current GUI concepts are not very practical when you want to find/play one specific song in a collection of many thousand. We consider this the top issue atm in order to make Elisa not only look nice but be really nice :)
In Elisa related news the first official release of Coherence happened today. Coherence is a Python Upnp framework developed by Frank Scholz and is the framework we use for all the upnp goodness in Elisa.
ffmpeg pains
Back in the day we tried relaying on ‘released’ versions of ffmpeg in GStreamer. The problem was that there never really was any releases of ffmpeg and the versions that floated around all tended to have different API’s. So what we discovered was that when distributions packaged GStreamer and a other multimedia systems using ffmpeg one or the other always tended to end up broken. So in the end we gave up on relying on ffmpeg as an external dependency and instead set up a system to ‘suck in’ snapshots of ffmpeg into the GStreamer ffmpeg plugin and thus avoid the problem of different applications conflicting due to relaying on different versions of ffmpeg.
Well it seems some of the major distro’s have decided that they want a return to the painful old days. The problem is that even to this day ffmpeg change its API’s more often than Linus Torvalds change his socks and they still don’t do proper releases, thus relaying on it as a shared library is a pain. Yet distributions in the name of security and not wanting duplicate copies of the code installed are now trying to get all their ffmpeg using systems to share one install. So if you get tons of weird error messages on your console when running a GStreamer application, please dont blame us, but instead email the package maintainer for your distribution with your frustrations.
“I will not write plural words with an apostrophe again.”
Ugh?! Blame the packagers for keeping our systems secure? Yeah right!
Why not just try to convince the ffmpeg crowd to try a better job at handling a stable API and bumping version and so-names when the break the ABI.
NoName: The alternative is not being unsecure. The alternative is adding the security patches more than one place.
it’s relying not relaying.
“please dont blame us, but instead email the package maintainer for your distribution with your frustrations”
sounds very familiar, not going to work though if past experience is anything to go by you’ll get blamed and all distributions will have succeeded in doing is to increase your support workload.
forewarned is forearmed, good to have a warning on record.
Hooray! to the win32 and osx effort.
Maybe just anyone should ‘export’ specific ffmpeg cvs versions to release-like tarballs?
Nice… it’s probably worth noting here that getting “tons of weird error messages on your console when running a GStreamer application,” when running a Gstreamer application is quite normal… ffmpeg or not. So are random freezes and high CPU use for simple sound playback.
Whether ffmpeg has good release procedures or not, Gstreamer crashes… a lot. It’s one of the buggiest pieces of software in a Linux distro, and after… what… 5 years of work, that says a lot about the broken original design and the lack of clue of the current developers.
Tell them about your comical release procedures, Schaller. Go on.. explain about how not so long ago you ended up with two versions of Gstreamer installed with every GNOME desktop because of Fluendo power games and the general incompetence of its developers.
Writing software based on Gstreamer is like tap dancing in a minefield.
You are completely misunderstanding the point of using a single ffmpeg instance. Let’s take an average distribution with a few popular media players: ffplay, mplayer, xine, vlc, GStreamer. Each time there is a security bug in ffmpeg (and recent experiments like zzuff showed we are likely to find more and more ones), you have to issue a security advisory for no less than five packages. When patching a beast like ffmpeg is horrible, patching it five times is what the security guys call a nightmare. Whatever you say, this is simply *not possible*. In Debian, we are down to “only” three, as the xine and vlc maintainers are using the Debian ffmpeg library. In fact, we could be down to one, but the GStreamer change was delayed post-etch, and the mplayer maintainer is just as brain-dead as the upstream mplayer developers (static linking teh r0><0rZ 178% sp33d 1mpr0v3m3nt lolZ).
The reason all of this is possible is that the Debian ffmpeg maintainer is committed to provide API stable packages for reasonable periods of times. Even better, security updates don’t even require more than one build because he provides a shared library with a *stable ABI*. Just like any f*cking stupid library in the system (yes, even libxul, which gets the same treatment). Of course, stabilizing these ffmpeg packages is critical but it’s done very carefully by a developer who knows well these issues, and it simplifies considerably our development process. When there is a ffmpeg related issue, there is no need to blame all GStreamer, xine, vlc and mplayer developers: we can just deal with the issue at a single place. Sure, we have to maintain that interface which is distribution-specific, but a distribution like Debian is a large enough organization to do that, and the gains are *huge*.