GNOME Bugzilla – Bug 161922
script to provide plugin installation info
Last modified: 2007-01-11 15:08:35 UTC
I'd like to add a method for apps (like rhythmbox) to get information from the distribution about how to install plugins. I.e., the current situation has rhythmbox popping up a dialog that says "cannot find element 'audioscale'". I'd like to see it say "The element 'audioscale' is not installed. Please install the package 'gstreamer0.8-misc'", and possibly have a button 'Install package', which would run the distro's/desktop's choice of package manager. In addition, this should be able to relate mime-types to packages. Implementation of the element-to-package and mime-type-to-package script is, of course, the duty of the distribution. This bug only concerns handling the mechanism.
Didn't we close the exact same bug 2 years ago as out-of-scope?
No, that one proposed a 'download service', which was definitely out-of-scope. This would just create hooks, and distributions could fill in the rest. An enterprising developer could also use the hooks to automatically download plugins, but I am specifically uninterested in that.
See also https://launchpad.net/distros/ubuntu/+spec/easy-codec-installation and https://wiki.ubuntu.com/EasyCodecInstallation
(In reply to comment #1) > Didn't we close the exact same bug 2 years ago as out-of-scope? > As David mentions, this is a relevant report. Empirically, I have seen several Ubuntu/GNOME installations that the end-users are baffled that MP3/video files are not playable and respond with "Totem cannot play these files". There is a sad misconception building up that totem/rhythmbox are not good. The current error dialog box when a codec is not found to play a media file is really confusing. What is the best way to load up the system's package manager and instruct it to install the multimedia packages?
Some more links at wiki.ubuntu.com, which provide information on the support from the distribution part. https://wiki.ubuntu.com/RestrictedFormatsAssistant https://wiki.ubuntu.com/RestrictedFormatsProblem https://wiki.ubuntu.com/RestrictedFormatsSolutions It appears that this is not a gstreamer problem per se. GStreamer should simply provide a mechanism to inform the distribution that a codec (or codecs) are not available. The distribution has the responsibility to find the codec or report that no codec can be used (and why).
Addendum: this mechanism should be able to handle missing source elements for certain URI protocols as well (e.g. when mmssrc is required to play mms:// streams), not only missing decoders/demuxers.
This document has some details about the planned mechanism on the GStreamer side of things: http://webcvs.freedesktop.org/gstreamer/gstreamer/docs/random/draft-missing-plugins.txt?view=markup
The concept described in draft-missing-plugins.txt is also quite interesting for content creation tools (pitivi, jokosher, buzztard). There we have to deal with the usecase that party A creates a project, sends it to B and B missies one of more GstElements. Can we clarify a few things in the draft? The entire ID string example given there is 'gstreamer.net|0.10|totem|Vorbis audio decoder|decoder-audio/x-vorbis' * how is the 'Vorbis audio decoder' part generated? caps and name? * could that app help here, e.g. when the app loads a projects a notices a missing element, I belive it knows from its project file format, if the element is a source (generator) or an effect. * can we add wrapper plugins there as an open issue, e.g. the project loader notices that ladspa-superbass is missing: ** how do we figure out that this is provided by the ladspa wrapper and what the real name is (establish a naming convention for wrappers? '<wrapper>-<elementname>') ** if above is solved we could check if ladspa is installed and if not -> gstreamer.net|0.10|zzz|LADSPA plugin wrapper|ladspa or if ladspa is there -> ladspa.org|1.0|zzz|LADSPA sound generator|superbass ** this affects: ladspa, libvirtual, pitdfll, bml (buzztards buzzmachine wrapper) and has a dependency on bug #350477
> Can we clarify a few things in the draft? Yes, I was waiting for the API for this to be finalized and committed first (bug #392393). > The entire ID string example given there is > 'gstreamer.net|0.10|totem|Vorbis audio decoder|decoder-audio/x-vorbis' > > * how is the 'Vorbis audio decoder' part generated? caps and name? Answer 1: the application shouldn't worry about this, it should just get the entire detail string using gst_missing_plugin_message_get_installer_detail() Answer 2: you could get it yourself by calling gst_base_utils_get_decoder_description() with audio/x-vorbis caps. > * could that app help here, e.g. when the app loads a projects > a notices a missing element, I believe it knows from its > project file format, if the element is a source (generator) > or an effect. Not sure what you mean here. Do you mean that if you post a missing-plugin message for an element (by element-name rather than decoder caps) the string you get is just a generic 'GStreamer foobar element' and you want to supply hints so it becomes something like 'foobar waveform generator' or so? I think this kind of thing should either go into gst_base_utils_get_element_description() or be completely up to the application. > * can we add wrapper plugins there as an open issue yes, good point, that should be mentioned so packagers are at least aware of this.
> Not sure what you mean here. Do you mean that if you post a missing-plugin > message for an element (by element-name rather than decoder caps) the string > you get is just a generic 'GStreamer foobar element' and you want to supply > hints so it becomes something like 'foobar waveform generator' or so? I think > this kind of thing should either go into > gst_base_utils_get_element_description() or be completely up to the > application. I was just thinking to say e.g. 'GStreamer foobar source element' or in the wrapper case 'LADSPA superbass source element'. Basically allow the application to optionally supply a default string to gst_element_post_missing_element_message() with that text, as the app might know more here.
> I was just thinking to say e.g. 'GStreamer foobar source element' or in the > wrapper case 'LADSPA superbass source element'. Basically allow the application > to optionally supply a default string to > gst_element_post_missing_element_message() with that text, as the app might > know more here. This looks more like an issue with the API in bug #392393. Now that we only have message creation functions for that stuff, all you need to do is add a gst_missing_plugin_message_set_description() function or so to libgstbaseutils. The plugin can then override the default description with a different one before posting it on the bus.
Updated draft-missing-plugins.txt as suggested: 2007-01-11 Tim-Philipp Müller <tim at centricular dot net> * docs/random/draft-missing-plugins.txt: Some additions: mention new API that is supposed to be used at the various stages; short blob about new gst-inspect introspection option; mention potential future problem with plugins that have a dynamic list of elements (such as ladspa, pitfdll, libvisual). Also implemented what the bug report initially asked for: 2007-01-11 Tim-Philipp Müller <tim at centricular dot net> * gst/playback/gstplaybin.c: (post_missing_element_message), (gen_video_element), (gen_text_element), (gen_audio_element), (gen_vis_element): Post missing-plugin messages also when we error out because converters, textoverlay or auto*sinks are missing (#161922). I think this bug can be closed now.