what are your program language and GUI packages(like Qt) in your product?
is your product launched at start-up of the target computer?
Do you use any gstreamer command in your code?
It is service, written on dotnet core. It uses gstreamer and it’plugins – good, bad, ugly and so on. Nothing fancy (I’ve already posted my pipeline here). I need to properly setup env. so my service could use gstreamer. gst-env.py seems ok, but it is explicitly stated that it is for development and it doing redundant things like create new session. I want something simple and robust. Some simple shell script which configure gst environment for production use and laucnh my service app.
The larger GStreamer build system, cerbero, does provide a gst-env script for non standard prefix installation. Though we don’t have that as part of our low level build system meson. Meson offser an uninstalled way to run GStreamer with meso devenv, but this is a developer tools, not really for production.
The GStreamer core library locates GStreamer plugins by default already based on the prefix it was configured for, so as long as you pull in the right GStreamer (+ glib + any other deps) that should work fine out of the box already. If you have to force it (which you shouldn’t have to in the installed case) there’s GST_PLUGIN_SYSTEM_PATH, see Running GStreamer Applications for this and other environment variables.
Others are more general system environment variables that are not GStreamer specific, e.g. LD_LIBRARY_PATH to make the run-time linker look in specific prefixes (that are not in the global config file), or PKG_CONFIG_PATH to make pkg-config pick up the right .pc files for development purposes (if you want to develop/build against that non-standard-prefix installation).
I guess what you did is not right. Do not build any package or app under root. Instead, install it under /opt/
And you are showing build dir. You have not installed gstreamer.
git clone the source code somewhere under Videos dir or your working dir.
Build it there and install the build under /opt/. Do not build it under root.
I didn’t buld src under root. It is installed (cloned) under /opt (see img above). Am I right that I need to init LD_LIBRARY_PATH with each folder with *.so
in /opt/gstreamer/builddir/subprojects/ ? Can you share main ideas of your init code? In my case it looks like:
Thank you so much again, will try. For now I have problem with setting env variables on Linux, Ubunta. In code (dotnet core project) I setup LD_LIBRARY_PATH and GST_PLUGIN_PATH – doesn’t work, can’t find libgstreamer. Env. variables are set, because I can print them.
If I setup them in shell and run my app – everything is fine. I think that gst is looking in a parent proc (shell) environment for needed variable or somehow ignores them. So, it seems to be more fundamental problem.
Is your app under Linux and use C++/C ? You just setup env variables and call gst_init?
Namely, I add /opt/gstreamer/bin to PATH and create LD_LIBRARY_PATH in code. Doesn’t work. If I set (export) before my app, everything works.
What I’m doing wrong? I don’t think that it relates somehow to installation. With ninja it is more elegant but I did basically the same, just added much more folders (copy-paste from gst-env.py). I don’t understand what I’m missing…
your gstreamer bin path is the last one and will be selected only when no other gstreamer bin path is available. I guess you have one in your system. Put it to the first to override system path. Also try to set the plugin path as well.
The point is to setup env variables by application itself. I setup it in code. Part of env variables of my process you can see above, the problem is that gst doesn’t see them. It seems to be problem of parent-child environment difference. Probably gst looks env vars in parent (process) environment or smth similiar. If I setup env vars in code – it doesn’t work, if in shell (parent process), it works.
Moreover, following approach works great: export LD_LIBRARY_PATH=/opt/gstreamer/lib && dotnet app.dll
but in this case I have to create intermediate shell script file which is not great.
So, setting env vars externally to app – works, setting very same env vars in app – doesn’t work. And I have no clue why.
Yes, it is ok, it is dotnet. Dotnet now (almost 5-6 years actually) works on Linux, so one can build cross-platform application. Hence dll. It works, it is not a problem.
