Seems like bundling the plugins (as a start, all the ones installed should be installed) and then setting an env var is enough. See ubuntu/snapcraft-desktop-helpers#49 and https://developer.gnome.org/gstreamer/stable/gst-running.html.

Therefore: blocked by #81.

Here is an example:
FrancescoCeruti/linux-show-player#53
Also see:
https://github.com/GStreamer/gstreamer/blob/master/scripts/gst-uninstalled

Now that the feature is there in linuxdeploy, we could make such a plugin. Volunteers welcome, though; this needs some testing. Writing plugins for linuxdeploy is quite easy, as even shell scripts can be used. @probonopd wanna give it a try?

To be honest I would not even know where to begin.

I guess bundling all GStreamer plugins and then setting the two or three environment variables required to make GStreamer find them should do. Perhaps we'll find some user who needs GStreamer support and implements that then. I don't have a GStreamer app on hand that I could test this with, let's rather do it once there's someone who needs that.

Also see strawberrymusicplayer/strawberry-buildbot@19cd165 where @jonaski has added GStreamer to the AppImage for the Strawberry music player.

I was using the continuous builds of linuxdeploy previously, but had to compile my own now because the builds of linuxdeploy-plugin-qt switched to Xenial which has newer glibc than Centos 7. I use Centos 7 for the AppImages because it's the most suitable distro I found since it has older core libraries but still has acceptable versions of Qt and GStreamer. I only have to compile chromaprint and sqlite3 myself. The Dockerfile is here: https://github.com/jonaski/strawberry-buildbot/blob/master/worker-centos-7/Dockerfile
I was previously setting the environment variables for GStreamer (GST_PLUGIN_SCANNER and GST_PLUGIN_SYSTEM_PATH) in the AppRun script, but I think in a newer version of linuxdeploy it gets overridden. So I switched to setting the environment variables in the source code instead, it's the same way I do it for macOS and Windows anyway. That's the commit you referer to.
The gstreamer plugins does not locate their dependencies when the plugins are in it's own directory, i.e.: /usr/plugins/gstreamer, to workaround that I copy the plugins directly into /usr/lib and symlink /usr/plugins/gstreamer to ../lib, would be nice if you have a solution to fix that. Other than that it's working fine now (except for Qt styling). I think Qt styling should be fixable by copying some theme dependencies into the AppDir, but not sure what files I need. Any suggestions?
The whole script is here: https://github.com/jonaski/strawberry-buildbot/blob/master/config/master/strawberry/builders.py#L385
I only bundle the required plugins for audio, not video.

switched to Xenial which has newer glibc than Centos 7

Argh. Maybe we should not have switched then @TheAssassin?

@jonaski just to be precise, do you want to bundle GStreamer and its plugins inside the AppImage or do you want the application in the AppImage to use GStreamer plugins that are installed on the system? (The latter is probably a sure recipe for disaster.)

I want to bundle them in /usr/plugins/gstreamer inside the appimage, instead of having to put them directly in /usr/lib in the appimage like now.

I see; you mean usr/plugins/gstreamer or usr/lib then, without a leading / ;-)

Regarding your question: @TheAssassin?

switched to Xenial which has newer glibc than Centos 7

Argh. Maybe we should not have switched then @TheAssassin?

Please open a separate bug, as I did in linuxdeploy-plugin-qt.

I want to bundle them in /usr/plugins/gstreamer inside the appimage, instead of having to put them directly in /usr/lib in the appimage like now.

I was previously setting the environment variables for GStreamer (GST_PLUGIN_SCANNER and GST_PLUGIN_SYSTEM_PATH) in the AppRun script, but I think in a newer version of linuxdeploy it gets overridden.

Can you please open an issue describing the problem? You know, without user feedback, bugs will live forever. We need your help there.
I've recently made changes regarding AppRun deployment. I did elaborate testing, but it seems your use case was broken. Since you already implemented workarounds, it'll be very hard for me to reproduce your exact situation. The PR in question is #87, the issue is #81. You can see the motivation for the changes there.

I will have a look at making a plugin for this in the future, but it's not a priority right now. I'll check out what @jonaski does there, and perhaps he can help test that plugin then.

Please open issues about the separate problems. It's annoying to have too much off-topic in an issue. Rather open too many issues than too few, I hate scrolling and I can close duplicates easily.

After taking a look into the gstreamer code I found that the following environment configuration is required, yet some gstreamer plugins are really bad and must be manually excluded.

export GST_REGISTRY_REUSE_PLUGIN_SCANNER="no"
export GST_PLUGIN_SYSTEM_PATH_1_0="${APPDIR}/usr/lib/x86_64-linux-gnu/gstreamer-1.0/"

export GST_PLUGIN_SCANNER_1_0="${APPDIR}/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner"
export GST_PTP_HELPER_1_0="${APPDIR}/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper"

yet some gstreamer plugins are really bad and must be manually excluded.

Which ones? Is there a list?

Which ones?

Usually the ones from the grstreamer-plugins-bad package but the list varies depending on the version. And not all the plugins in that package cause a segfault

You can still bundle those though, right? I mean, unless they're loaded, they should be harmless.

You can still bundle those though, right? I mean, unless they're loaded, they should be harmless.

There is a gst-plugin-scanner that is used to locate plugins when the app starts. The crash actually happens when it scans those troublesome plugins. Maybe there is another lib that is not being properly bundled and that's why the crash but so far removing those plugins from the bundle fix the issue.

I can't find a tool called gst-plugin-scanner, any references you can share?

On Fedora: /usr/libexec/gstreamer-1.0/gst-plugin-scanner
On Debian: /usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner

I'm not entirely sure how this binary is supposed to work.

I think for now it should suffice to just copy over all plugins. If the app doesn't load them, nothing bad will happen, it's just additional bloat. We have to get started somewhere.

If the app doesn't load them, nothing bad will happen

The gst-plugin-scanner scans the plugins at startup and in some cases it doesn't ignores broken plugins gracefully in which case a segfaults is produced.

What do these two do?

export GST_REGISTRY_REUSE_PLUGIN_SCANNER="no"
export GST_PTP_HELPER_1_0="${APPDIR}/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper"

The gst-plugin-scanner always finds plugins in the system rather than in the AppDir, do you know how to change that?

The gst-plugin-scanner always finds plugins in the system rather than in the AppDir, do you know how to change that?

That's what GST_REGISTRY_REUSE_PLUGIN_SCANNER="no" is for.

There is another binary that gstreamer uses which is: GST_PTP_HELPER_1_0

Yet when gstreamer is embed into the AppImage the startup time increases considerably due the plugins cache being updated (and failing to load the plugins in the system). Yet, it works :)

Experimental implementation can be found here: https://github.com/linuxdeploy/linuxdeploy-plugin-gstreamer

There is the unsolved problem that the dependencies of these libraries aren't deployed. CC #68

Maybe the script could use an environment variable for what gstreamer plugins to bundle. I only want to bundle the required audio plugins.

Working implementation provided in https://github.com/linuxdeploy/linuxdeploy-plugin-gstreamer. Feel free to open issues there. Contributions welcome!

Looking at

https://github.com/probonopd/go-appimage/blob/2fdd76609e99ed4286adb5cc696c0fe570c65721/src/appimagetool/appdirtool.go#L667-L695

one issue seems to be that you find gst-plugin-scanner but due to the typical Desktop Linux Platform Issues (different distributions agreeing on nothing) you can never know where it hides...

I have seen it at least in

• /usr/libexec/gstreamer-1.0/gst-plugin-scanner (Clear Linux OS)
• /usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner (Ubuntu 18.04; look at that ugly inconsistent gstreamer1.0/gstreamer-1.0)

Things like this are the reason why I am increasingly fond of using FreeBSD instead of "Linux".