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.

Maybe just anyone should ‘export’ specific ffmpeg cvs versions to release-like tarballs?

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.

]]> http://blogs.gnome.org/uraeus/2007/02/15/gst-phonon-code-now-public/comment-page-1/#comment-916 Np237 Wed, 30 Nov -0001 00:00:00 +0000 http://blogs.gnome.org/uraeus/2007/02/15/gst-phonon-code-now-public/#comment-916 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).<p/>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*. 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*.