gladium makes a good point. I think it's clear that if we enabled the gstreamer backend in official builds, we'd want to include our own build. But that doesn't help if it's not abi compatible with the elements we want to use on the system.
I just tried loading the fluendo binary elements for gstreamer-0.10 with today's git (gstreamer 1.0.0) and it wasn't able to find the entry points:
WARN GST_PLUGIN_LOADING gstplugin.c:383:gst_plugin_register_func: plugin "/home/giles/gstreamer/fluendo-bin/libgstflump3dec.so" has incompatible version, not loading
So while I thought it was clear official biulds would include their own builds of gstreamer if we enabled this back end, that doesn't help if we can't load elements from the system gstreamer install.
We could still pick a target version and only support that, which is easier to do now that gstreamer 1.0 is released. That might be ok if we could fall back to our built-in decoders when the requested elements aren't available.
gladium makes a good point. I think it's clear that if we enabled the gstreamer backend in official builds, we'd want to include our own build. But that doesn't help if it's not abi compatible with the elements we want to use on the system.
I just tried loading the fluendo binary elements for gstreamer-0.10 with today's git (gstreamer 1.0.0) and it wasn't able to find the entry points:
WARN GST_PLUGIN_LOADING gstplugin. c:383:gst_ plugin_ register_ func: plugin "/home/ giles/gstreamer /fluendo- bin/libgstflump 3dec.so" has incompatible version, not loading
So while I thought it was clear official biulds would include their own builds of gstreamer if we enabled this back end, that doesn't help if we can't load elements from the system gstreamer install.
We could still pick a target version and only support that, which is easier to do now that gstreamer 1.0 is released. That might be ok if we could fall back to our built-in decoders when the requested elements aren't available.