## gstpbutilsinstallplugins gstpbutilsinstallplugins — Missing plugin installation support for applications |

## Synopsis

    #include <gst/pbutils/install-plugins.h>

    enum                GstInstallPluginsReturn;
    void                (*GstInstallPluginsResultFunc)      (GstInstallPluginsReturn result,
                                                             gpointer user_data);
    GstInstallPluginsReturn  gst_install_plugins_async      (gchar **details,
                                                             GstInstallPluginsContext *ctx,
                                                             GstInstallPluginsResultFunc func,
                                                             gpointer user_data);
    GstInstallPluginsReturn  gst_install_plugins_sync       (gchar **details,
                                                             GstInstallPluginsContext *ctx);
    const gchar *       gst_install_plugins_return_get_name (GstInstallPluginsReturn ret);
    gboolean            gst_install_plugins_installation_in_progress
                                                            (void);
    gboolean            gst_install_plugins_supported       (void);

                        GstInstallPluginsContext;
    GstInstallPluginsContext *  gst_install_plugins_context_new
                                                            (void);
    void                gst_install_plugins_context_free    (GstInstallPluginsContext *ctx);
    void                gst_install_plugins_context_set_xid (GstInstallPluginsContext *ctx,
                                                             guint xid);

## Description

### Overview

Using this API, applications can request the installation of missing GStreamer plugins. These may be missing decoders/demuxers or encoders/muxers for a certain format, sources or sinks for a certain URI protocol (e.g. 'http'), or certain elements known by their element factory name ('audioresample').

Whether plugin installation is supported or not depends on the operating system and/or distribution in question. The vendor of the operating system needs to make sure the necessary hooks and mechanisms are in place for plugin installation to work. See below for more detailed information.

From the application perspective, plugin installation is usually triggered either

- when the application itself has found that it wants or needs to install a certain element

- when the application has been notified by an element (such as playbin or decodebin) that one or more plugins are missing and the application has decided that it wants to install one or more of those missing plugins

The install functions in this section all take one or more 'detail strings'. These detail strings contain information about the type of plugin that needs to be installed (decoder, encoder, source, sink, or named element), and some additional information such GStreamer version used and a human-readable description of the component to install for user dialogs.

Applications should not concern themselves with the composition of the string itself. They should regard the string as if it was a shared secret between GStreamer and the plugin installer application.

Detail strings can be obtained using the function `gst_missing_plugin_message_get_installer_detail()` on a missing-plugin message. Such a message will either have been found by the application on a pipeline's GstBus, or the application will have created it itself using `gst_missing_element_message_new()`, `gst_missing_decoder_message_new()`, `gst_missing_encoder_message_new()`, `gst_missing_uri_sink_message_new()`, or `gst_missing_uri_source_message_new()`.

For each GStreamer element/plugin/component that should be installed, the application needs one of those 'installer detail' string mentioned in the previous section. This string can be obtained, as already mentioned above, from a missing-plugin message using the function `gst_missing_plugin_message_get_installer_detail()`. The missing-plugin message is either posted by another element and then found on the bus by the application, or the application has created it itself as described above.

The application will then call `gst_install_plugins_async()`, passing a NULL-terminated array of installer detail strings, and a function that should be called when the installation of the plugins has finished (successfully or not). Optionally, a GstInstallPluginsContext created with `gst_install_plugins_context_new()` may be passed as well. This way additional optional arguments like the application window's XID can be passed to the external installer application.

`gst_install_plugins_async()` will return almost immediately, with the return code indicating whether plugin installation was started or not. If the necessary hooks for plugin installation are in place and an external installer application has in fact been called, the passed in function will be called with a result code as soon as the external installer has finished. If the result code indicates that new plugins have been installed, the application will want to call `gst_update_registry()` so the run-time plugin registry is updated and the new plugins are made available to the application.

### Note

A Gtk/GLib main loop must be running in order for the result function to be called when the external installer has finished. If this is not the case, make sure to regularly call

    g_main_context_iteration (NULL,FALSE);

from your code.

1. Installer hook

When GStreamer applications initiate plugin installation via `gst_install_plugins_async()` or `gst_install_plugins_sync()`, a pre-defined helper application will be called.

The exact path of the helper application to be called is set at compile time, usually by the `./configure` script based on the install prefix. For a normal package build into the `/usr` prefix, this will usually default to `/usr/libexec/gst-install-plugins-helper` or `/usr/lib/gst-install-plugins-helper`.

Vendors/distros who want to support GStreamer plugin installation should either provide such a helper script/application or use the `./configure` option `--with-install-plugins-helper=/path/to/installer` to make GStreamer call an installer of their own directly.

It is strongly recommended that vendors provide a small helper application as interlocutor to the real installer though, even more so if command line argument munging is required to transform the command line arguments passed by GStreamer to the helper application into arguments that are understood by the real installer.

The helper application path defined at compile time can be overriden at runtime by setting the `GST_INSTALL_PLUGINS_HELPER` environment variable. This can be useful for testing/debugging purposes.

2. Arguments passed to the install helper

GStreamer will pass the following arguments to the install helper (this is in addition to the path of the executable itself, which is by convention argv[0]):

- none to many optional arguments in the form of `--foo-bar=val`. Example: `--transient-for=XID` where XID is the X Window ID of the main window of the calling application (so the installer can make itself transient to that window). Unknown optional arguments should be ignored by the installer.

- one 'installer detail string' argument for each plugin to be installed; these strings will have a `gstreamer` prefix; the exact format of the detail string is explained below

3. Detail string describing the missing plugin

The string is in UTF-8 encoding and is made up of several fields, separated by '|' characters (but neither the first nor the last character is a '|'). The fields are:

- plugin system identifier, ie. "gstreamer"

  This identifier determines the format of the rest of the detail string. Automatic plugin installers should not process detail strings with unknown identifiers. This allows other plugin-based libraries to use the same mechanism for their automatic plugin installation needs, or for the format to be changed should it turn out to be insufficient.

- plugin system version, e.g. "0.10"

  This is required so that when there is a GStreamer-0.12 or GStreamer-1.0 at some point in future, the different major versions can still co-exist and use the same plugin install mechanism in the same way.

- application identifier, e.g. "totem"

  This may also be in the form of "pid/12345" if the program name can't be obtained for some reason.

- human-readable localised description of the required component, e.g. "Vorbis audio decoder"

- identifier string for the required component (see below for details about how to map this to the package/plugin that needs installing), e.g.

  - urisource-$(PROTOCOL_REQUIRED), e.g. urisource-http or urisource-mms

  - element-$(ELEMENT_REQUIRED), e.g. element-ffmpegcolorspace

  - decoder-$(CAPS_REQUIRED), e.g. (do read below for more details!):

    - decoder-audio/x-vorbis

    - decoder-application/ogg

    - decoder-audio/mpeg, mpegversion=(int)4

    - decoder-video/mpeg, systemstream=(boolean)true, mpegversion=(int)2

  - encoder-$(CAPS_REQUIRED), e.g. encoder-audio/x-vorbis

- optional further fields not yet specified

An entire ID string might then look like this, for example: `gstreamer|0.10|totem|Vorbis audio decoder|decoder-audio/x-vorbis`

Plugin installers parsing this ID string should expect further fields also separated by '|' symbols and either ignore them, warn the user, or error out when encountering them.

Those unfamiliar with the GStreamer 'caps' system should note a few things about the caps string used in the above decoder/encoder case:

- the first part ("video/mpeg") of the caps string is a GStreamer media type and not a MIME type. Wherever possible, the GStreamer media type will be the same as the corresponding MIME type, but often it is not.

- a caps string may or may not have additional comma-separated fields of various types (as seen in the examples above)

- the caps string of a 'required' component (as above) will always have fields with fixed values, whereas an introspected string (see below) may have fields with non-fixed values. Compare for example:

  - `audio/mpeg, mpegversion=(int)4` vs. `audio/mpeg, mpegversion=(int){2, 4}`

  - `video/mpeg, mpegversion=(int)2` vs. `video/mpeg, systemstream=(boolean){ true, false}, mpegversion=(int)[1, 2]`

4. Exit codes the installer should return

The installer should return one of the following exit codes when it exits:

- 0 if all of the requested plugins could be installed (GST_INSTALL_PLUGINS_SUCCESS)

- 1 if no appropriate installation candidate for any of the requested plugins could be found. Only return this if nothing has been installed (GST_INSTALL_PLUGINS_NOT_FOUND)

- 2 if an error occured during the installation. The application will assume that the user will already have seen an error message by the installer in this case and will usually not show another one (GST_INSTALL_PLUGINS_ERROR)

- 3 if some of the requested plugins could be installed, but not all (GST_INSTALL_PLUGINS_PARTIAL_SUCCESS)

- 4 if the user aborted the installation (GST_INSTALL_PLUGINS_USER_ABORT)

5. How to map the required detail string to packages

It is up to the vendor to find mechanism to map required components from the detail string to the actual packages/plugins to install. This could be a hardcoded list of mappings, for example, or be part of the packaging system metadata.

GStreamer plugin files can be introspected for this information. The `gst-inspect` utility has a special command line option that will output information similar to what is required. For example $ gst-inspect-0.10 --print-plugin-auto-install-info /path/to/libgstvorbis.so should output something along the lines of `decoder-audio/x-vorbis element-vorbisdec element-vorbisenc element-vorbisparse element-vorbistag encoder-audio/x-vorbis` Note that in the encoder and decoder case the introspected caps can be more complex with additional fields, e.g. `audio/mpeg,mpegversion=(int){2,4}`, so they will not always exactly match the caps wanted by the application. It is up to the installer to deal with this (either by doing proper caps intersection using the GStreamer GstCaps API, or by only taking into account the media type).

Another potential source of problems are plugins such as ladspa or libvisual where the list of elements depends on the installed ladspa/libvisual plugins at the time. This is also up to the distribution to handle (but usually not relevant for playback applications).

## Details

### enum GstInstallPluginsReturn

    typedef enum {
      /* Return codes from the installer. Returned by gst_install_plugins_sync(),
       * or passed as result code to your #GstInstallPluginsResultFunc */
      GST_INSTALL_PLUGINS_SUCCESS = 0,
      GST_INSTALL_PLUGINS_NOT_FOUND = 1,
      GST_INSTALL_PLUGINS_ERROR = 2,
      GST_INSTALL_PLUGINS_PARTIAL_SUCCESS = 3,
      GST_INSTALL_PLUGINS_USER_ABORT = 4,

      /* Returned by gst_install_plugins_sync(), or passed as result code to your
       * #GstInstallPluginsResultFunc */
      GST_INSTALL_PLUGINS_CRASHED = 100,
      GST_INSTALL_PLUGINS_INVALID,

      /* Return codes from starting the external helper, may be returned by both
       * gst_install_plugins_sync() and gst_install_plugins_async(), but should
       * never be seen by a #GstInstallPluginsResultFunc */
      GST_INSTALL_PLUGINS_STARTED_OK = 200,
      GST_INSTALL_PLUGINS_INTERNAL_FAILURE,
      GST_INSTALL_PLUGINS_HELPER_MISSING,
      GST_INSTALL_PLUGINS_INSTALL_IN_PROGRESS
    } GstInstallPluginsReturn;

Result codes returned by `gst_install_plugins_async()` and `gst_install_plugins_sync()`, and also the result code passed to the GstInstallPluginsResultFunc specified with `gst_install_plugin_async()`.

These codes indicate success or failure of starting an external installer program and to what extent the requested plugins could be installed.

`GST_INSTALL_PLUGINS_SUCCESS` | all of the requested plugins could be installed
`GST_INSTALL_PLUGINS_NOT_FOUND` | no appropriate installation candidate for any of the requested plugins could be found. Only return this if nothing has been installed. Return GST_INSTALL_PLUGINS_PARTIAL_SUCCESS if some (but not all) of the requested plugins could be installed.
`GST_INSTALL_PLUGINS_ERROR` | an error occured during the installation. If this happens, the user has already seen an error message and another one should not be displayed
`GST_INSTALL_PLUGINS_PARTIAL_SUCCESS` | some of the requested plugins could be installed, but not all
`GST_INSTALL_PLUGINS_USER_ABORT` | the user has aborted the installation
`GST_INSTALL_PLUGINS_CRASHED` | the installer had an unclean exit code (ie. death by signal)
`GST_INSTALL_PLUGINS_INVALID` | the helper returned an invalid status code
`GST_INSTALL_PLUGINS_STARTED_OK` | returned by `gst_install_plugins_async()` to indicate that everything went fine so far and the provided callback will be called with the result of the installation later
`GST_INSTALL_PLUGINS_INTERNAL_FAILURE` | some internal failure has occured when trying to start the installer
`GST_INSTALL_PLUGINS_HELPER_MISSING` | the helper script to call the actual installer is not installed
`GST_INSTALL_PLUGINS_INSTALL_IN_PROGRESS` | a previously-started plugin installation is still in progress, try again later

Since 0.10.12

### GstInstallPluginsResultFunc ()

    void                (*GstInstallPluginsResultFunc)      (GstInstallPluginsReturn result,
                                                             gpointer user_data);

The prototype of the callback function that will be called once the external plugin installer program has returned. You only need to provide a callback function if you are using the asynchronous interface.

`result` : | whether the installation of the requested plugins succeeded or not
`user_data` : | the user data passed to `gst_install_plugins_async()`

Since 0.10.12

### gst_install_plugins_async ()

    GstInstallPluginsReturn  gst_install_plugins_async      (gchar **details,
                                                             GstInstallPluginsContext *ctx,
                                                             GstInstallPluginsResultFunc func,
                                                             gpointer user_data);

Requests plugin installation without blocking. Once the plugins have been installed or installation has failed, `func` will be called with the result of the installation and your provided `user_data` pointer.

This function requires a running GLib/Gtk main loop. If you are not running a GLib/Gtk main loop, make sure to regularly call g_main_context_iteration(NULL,FALSE).

The installer strings that make up `detail` are typically obtained by calling `gst_missing_plugin_message_get_installer_detail()` on missing-plugin messages that have been caught on a pipeline's bus or created by the application via the provided API, such as `gst_missing_element_message_new()`.

It is possible to request the installation of multiple missing plugins in one go (as might be required if there is a demuxer for a certain format installed but no suitable video decoder and no suitable audio decoder).

`details` : | NULL-terminated array of installer string details (see below)
`ctx` : | a GstInstallPluginsContext, or NULL
`func` : | the function to call when the installer program returns. [scope async]
`user_data` : | the user data to pass to `func` when called, or NULL. [closure]
Returns : | result code whether an external installer could be started

Since 0.10.12

### gst_install_plugins_sync ()

    GstInstallPluginsReturn  gst_install_plugins_sync       (gchar **details,
                                                             GstInstallPluginsContext *ctx);

Requests plugin installation and block until the plugins have been installed or installation has failed.

This function should almost never be used, it only exists for cases where a non-GLib main loop is running and the user wants to run it in a separate thread and marshal the result back asynchronously into the main thread using the other non-GLib main loop. You should almost always use `gst_install_plugins_async()` instead of this function.

`details` : | NULL-terminated array of installer string details
`ctx` : | a GstInstallPluginsContext, or NULL
Returns : | the result of the installation.

Since 0.10.12

### gst_install_plugins_return_get_name ()

    const gchar *       gst_install_plugins_return_get_name (GstInstallPluginsReturn ret);

Convenience function to return the descriptive string associated with a status code. This function returns English strings and should not be used for user messages. It is here only to assist in debugging.

`ret` : | the return status code
Returns : | a descriptive string for the status code in `ret`

Since 0.10.12

### gst_install_plugins_installation_in_progress ()

    gboolean            gst_install_plugins_installation_in_progress
                                                            (void);

Checks whether plugin installation (initiated by this application only) is currently in progress.

Returns : | TRUE if plugin installation is in progress, otherwise FALSE

Since 0.10.12

### gst_install_plugins_supported ()

    gboolean            gst_install_plugins_supported       (void);

Checks whether plugin installation is likely to be supported by the current environment. This currently only checks whether the helper script that is to be provided by the distribution or operating system vendor exists.

Returns : | TRUE if plugin installation is likely to be supported.

Since 0.10.15

### GstInstallPluginsContext

    typedef struct _GstInstallPluginsContext GstInstallPluginsContext;

Opaque context structure for the plugin installation. Use the provided API to set details on it.

Since 0.10.12

### gst_install_plugins_context_new ()

    GstInstallPluginsContext *  gst_install_plugins_context_new
                                                            (void);

Creates a new GstInstallPluginsContext.

Returns : | a new GstInstallPluginsContext. Free with `gst_install_plugins_context_free()` when no longer needed

Since 0.10.12

### gst_install_plugins_context_free ()

    void                gst_install_plugins_context_free    (GstInstallPluginsContext *ctx);

Frees a GstInstallPluginsContext.

`ctx` : | a GstInstallPluginsContext

Since 0.10.12

### gst_install_plugins_context_set_xid ()

    void                gst_install_plugins_context_set_xid (GstInstallPluginsContext *ctx,
                                                             guint xid);

This function is for X11-based applications (such as most Gtk/Qt applications on linux/unix) only. You can use it to tell the external installer the XID of your main application window. That way the installer can make its own window transient to your application window during the installation.

If set, the XID will be passed to the installer via a --transient-for=XID command line option.

Gtk+/Gnome application should be able to obtain the XID of the top-level window like this:

    ##include <gtk/gtk.h>
    ##ifdef GDK_WINDOWING_X11
    ##include <gdk/gdkx.h>
    ##endif
    ...
    ##ifdef GDK_WINDOWING_X11
      xid = GDK_WINDOW_XWINDOW (GTK_WIDGET (application_window)->window);
    ##endif
    ...

`ctx` : | a GstInstallPluginsContext
`xid` : | the XWindow ID (XID) of the top-level application

Since 0.10.12