Ubuntu Wiki

Am I right in assuming the reason for wanting to do it at the GStreamer rather than application level is that it will Just Work without having to modify each application individually? While that sounds good, I don't know how practical it will be because it will require some fairly invasive changes, and will probably require application-level changes anyway.

Some applications (e.g. Rhythmbox, iirc amaroK) will automatically kill it's out-of-process metadata loader if it takes too long, as it is usually caused by a GStreamer plugin bug getting it stuck. Doing plugin installs without the application being aware of it will trigger those kinds of things. Doing it at the application level also lets apps be smarter about it, for example continuing to load all the user's Ogg Vorbis files while MP3 support is beig installed in the background.

Personally, I think a common library/tool that application could use (with different implementations for different distros) would be a better approach. It would also allow applications to use it for things which aren't purely "play my file" issues, such as applications saying "I need the 'trm' element to do audio fingerprinting" or "I need 'id3v2mux' to do ID3 tag editing" -- JamesLivingston (Rhythmbox developer)

• Perhaps Gstreamer can implement a null or dummy codec to prevent apps from assuming it has failed. I think that the more general the approach the better. Once a unified approach is sorted out upstreams will begin using it, and it can always be an optional feature for those ditros and users who do not wish to implement it.

Perhaps a better idea would be to simply create a simple program called Media Codec Manager or something... Then with gStreamer apps, we could link them together as proposed. But, the media codec manager would be application and platform independent. It could simply list all the video and audio codecs and allow you to check off which ones you want or have a button that says install all. Also, if you install support for say MP3, it will install both the gstreamer plugin as well as LAME for other apps like mplayer or vlc. -Derick_eisenhardt (2006-08-09 @ 17:42 CDT)

DVD playback requires libdvdcss2 which isn't just a missing gst plugin. I think that's why we need a more general approach here. If we can't install some stuff automatically, we must at least tell the user what the problem is and how to solve it and point him in the right direction. -- AndreRuediger

• Would it be possible to re-package libdvdcss2, so it acts like flashplugin-nonfree (i.e. uses dpkg -configure to help the user download and install the actual library) rather than the user having to run an install script. --KrisMarsh

On the Thin Client/LTSP side, making sure we get gstreamer/pulseaudio stack going will be crucial for making sure that multimedia on TC's works as well as locally. Both edubuntu (edu software), call centres (ekiga), etc. will need this. --ScottBalneaves

The current thinking about how this will be implemented internally in GStreamer and how it will look from the point of view of GStreamer applications can be found here: http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/random/draft-missing-plugins.txt?view=log --TimMüller (GStreamer developer)

However, I think we agreed that the actual request for a codec to be installed will be done by API that is in a separate library. That a) isolates the distribution-specific code without requiring multiple branches of gstreamer, and b) allows that process to involve UI without gstreamer suddenly acquiring UI code and all the dependencies that would involve. Ryan Lortie already has a skeleton project for this API. --MurrayCumming

• Yes, this is the plan in the above proposal as well. The structure with the install_plugins vfunc is provided by an external library and the IPC details will be done by that external library in whatever way it likes. --TimMüller (Update: the GStreamer doc has been updated again so that there won't be any API at all in GStreamer to initiate download, and so that the external library will handle all of it)

Notes from the meeting

...by JonoBacon.

GStreamer registry should not need updating.

Consideration of patent issues in installable codec plugins.

Much of the different chunks of the puzzle expectated to be developed in the next few months - everyone is aware of what needs doing.

Needs doing: gnome-app-install, gstreamer

Need a tool to build the database of packages. Inspection should be made at build time.

GStreamer side of things is planned and specced out.

Upstream apps will be patched for feisty and hopefully this system can be rolled out across other distributions.

Make a default script for those distros who have not implemented this system - "click here for more information".

Documentation should be made for upsream authors to ensure theirs apps implement this functionality.