general: How does gstreamer handle conflicting plugins?

[Sebastian Dröge]

Am Mittwoch, den 18.02.2009, 16:08 +0100 schrieb Fabian Greffrath:
> Thanks for your answers!
> 
> Sebastian Dröge schrieb:
> > As long as those plugins have a) different shared library files and b)
> > have different plugin and element names (you can have one GstPlugin per
> > shared library file and n GstElements per plugin, elements are the
> > things that are doing all the work ;)) they don't conflict.
> 
> Alright, I didn't mean conflicting in the context of software 
> packaging, but rather in the context of the purpose of the plugins.
> 
> > When GStreamer tries to find an element for decoding it chooses that
> > one, that provides the required feature (decoding of MP3 for example)
> > and has the highest rank (fluendo-mp3 has a higher rank than mad for
> > example). If there's more than one with the same rank the alphabetically
> > first one will be used.
> 
> This is the information that I needed, thanks! How can I find out the 
> rank of a specific plugin and who decides about the rank?

gst-inspect $element_name | grep Rank

btw, ranks below marginal won't be used automatically.

The ranks are hardcoded in the sources, the decision is done by the
distribution in the end (so we decided that pulsesink gets a higher rank
than every other audio output sink for example). The upstream rule for
this is essentially, that the best (feature/performance/stability-wise)
gets the highest rank (and third-party vendors use an even higher rank
for their plugins, the Fluendo plugins for example).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-gstreamer-maintainers/attachments/20090218/e25fc4ba/attachment.pgp