I have installed gstreamer-1.4.0 in order to create simple app for decoding video files.
The pipeline which I try to create looks simple:
filesrc location="file.h264" ! decodebin ! filesink location="file.raw"
This pipeline works fine when i launch it using gst-launch-1.0, however when I try to run my program written in C, it cannot find factory called "decodebin".
GstElementFactory *factory;
factory = gst_element_factory_find("decodebin");
if( !factory )
// fail
Above code always fails (factory is NULL). gst-inspect-1.0 recognizes "decodebin" correctly, so my guess is that something's wrong with GST_PLUGIN_PATH or something similar, but I have no idea how should I configure it properly. But it's just my guess based on the fact that my app creates other elements from factories such as filesrc or filesink which are in plugin called coreelements, and still decodebin which is from plugin 'playback' failes.
My question: How can i fix my gstreamer configuration in order to recognize all plugins, not just coreelements?
If i skipped some important info please let me know so that I could append it asap :)
// EDIT:
Let's say i've installed gstreamer from sources (i'm using ubuntu 14.04).
I've also installed all plugins (base, bag, good), also from sources.
Installation directory was /opt/gstreamer-1.4.0/, maybe this causes some problem.
If I execute command:
echo $GST_PLUGINS_PATH
all I get is an empty line, similar effect when i try to display values of other GST_* environmental variables.
more specific question: Which directories should I append to which variables in order to make non coreelements plugins work?
And if this question is too general, than:
how gst_element_factory_find("factory_name") checks if a given factory exists?
Don't know if what i did fixed everything, but for now i solved my problem by copying libplayback.so and other compiled plugins binaries to the folder with libcoreelements.so
It appears that the problem was caused by the non-standard installation directories,
so my solution is a hotfix, since I still don't know how was it possible that gst-inspect-1.0 recognized all plugins whilst gst_element_factory_find() couldn't. Any further inside will be appreciated :)
Related
I opened a project from a colleague in mplab X, it was in an archive(.zip) I added to the original path where are all my projects and I added the correct path to Harmony, but this is the error when I build. I configured it for the correct target board and compiller and on an clean&rebuild I get the same error. Any ideas how to fix that?
SOLUTION:
The project was in 1 extra folder with the same name, created when I extracted its content... I removed it, restarted the IDE, set it as main project, set the settings again for compiler and target board, run the harmony configurator, so it loaded some files and guess what... Worked like a charm... Can't believe the issue was 1 extra folder which was holding the project... Thank you for your help.
P.S: No, he was using the same OS.
I am trying to run the first tutorial on GStreamer and running into some issues.
When I compile the code found here and run it, no compilation errors or warnings occur and the stream is found, but only the audio plays. When I run the executable with the GST_DEBUG environment variable set to 3, then I get the following debug output:
0:00:00.312559000 5230 0x7f8326031ad0 FIXME videodecoder gstvideodecoder.c:928:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vp8dec0> Sub-class should implement drain()
0:00:00.355530000 5230 0x7f8325139ed0 FIXME videodecoder gstvideodecoder.c:928:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vp8dec0> Sub-class should implement drain()
0:00:00.355659000 5230 0x7f8325139ed0 FIXME videodecoder gstvideodecoder.c:928:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vp8dec0> Sub-class should implement drain()
So it seems like there is some error either in my install of the videodecoder or the videodecoder itself, I can't say for certain.
When I try running the same media directly from the gstreamer CLI using the command
./gst-launch-1.0 -v playbin uri=https://www.freedesktop.org/software/gstreamer-sdk/data/media/sintel_trailer-480p.webm
I get a small OpenGL window that plays both the video and audio without any hiccups.
When I tried to install GStreamer and its plugins from brew, I ran into issues with certain plugins missing (namely certain decoders and demuxeres like vorbisdec). When I run the gst-launch tool from the brew install, I get warnings regarding the missing vorbis decoder. In this case, video plays without incident but audio does not.
Could this be an issue with the GStreamer framework pointing to the wrong plugins or directories? How can I diagnose this and/or fix it? Any help is greatly appreciated!
You might be running into https://gitlab.freedesktop.org/gstreamer/gst-docs/-/issues/10: on macOS you need to have a GLib main-loop running in order to display an OpenGL window. So in the tutorial you'll need to add something along the lines of this to make it work:
// Construct main-loop
GMainLoop *main_loop;
main_loop = g_main_loop_new(NULL, FALSE);
(...)
// Run main-loop
g_main_loop_run(main_loop);
(...)
// Clean-up
g_main_loop_unref(main_loop);
See tutorial 12 for an example.
As for the plugins not working with the Homebrew installation, you'll need to specify the location of the plugins manually. Depending on where Homebrew installed them and which ones you installed, it might look something like this:
export GST_PLUGIN_SYSTEM_PATH="/usr/local/opt/gst-plugins-good/lib/gstreamer-1.0/:/usr/local/opt/gst-plugins-bad/lib/gstreamer-1.0/:/usr/local/opt/gst-plugins-base/lib/gstreamer-1.0/:/usr/local/opt/gstreamer/lib/"
I am using custom Nagios plugins for the first time and am running into this error when I create a service for the plugin.
(No output on stdout) stderr: execvp(/usr/local/nagios/libexec/check_load.py, ...) failed. errno is 2: No such file or directory
The plugin works when I run it on the command line, however does not work when it runs within Nagios.
I followed these steps to get the plugin into Nagios
https://assets.nagios.com/downloads/nagiosxi/docs/Managing-Plugins-in-Nagios-XI.pdf
Here is what it looks like in the Nagios UI
The plugin is in the correct path: /usr/local/nagios/libexec and the resource.cfg file has the same path within it.
I tried two separate plugins, both which work on the command line, and the result is the same error.
The error indicates the file location is incorrect, however the plugin is in the specified directory and runs with no errors within that directory.
I am totally stumped and appreciate any help.
For anyone reading this, I solved the problem.
The first time I added the plugin, I forgot to add the python extension. When I updated the already created plugin, Nagios still threw the error.
Once I completely deleted the plugin and re-created it the 'file not found', error went away.
I faced a similar issue when I was trying to add a custom plugin ( I had custom plugins in ruby and python ).
The issue was the missing shebang line at the start of the script (which determines the script's ability to be executed like a standalone executable).
For example, if you have a python plugin custom-plugin.py then make sure this script has shebang at the start of script #!/usr/bin/env python3. Also if you have other scripts (ruby, bash etc.) make sure to add the appropriate path at the start of your scripts.
Also, check the path for plugins Nagios version. For my setup path was /usr/local/nagios/libexec/ and make sure your custom plugin is executable and has correct ownership permissions.
Sample custom template I used :
define command {
command_name check_switch_health
command_line /usr/local/nagios/libexec/check_snmp.rb --host $HOSTADDRESS$ --model "$ARG1$" --community "$ARG2$"
}
The above workaround worked for me.
I just had to reinstall MacPorts after my upgrade to Yosemite. It was a great opportunity to not install tex-live again, because I prefer to use MacTeX. I believe it got installed as a dependency at one point in time.
What I'm wondering is if there is a way a can prevent it from ever being installed again. A port blacklist if you will, where even if it's a dependency it will not get installed. I'm fine with that port with that dependency failing as well.
Any help would be greatly appreciated.
This may be a stupid question, but why do you prefer MacTeX? Both the MacPorts TeXLive distribution and MacTeX contain exactly the same software anyway.
Nonetheless, for your specific question, no there is no blacklist. For the special case of LaTeX, you can edit your macports.conf and append /usr/texbin to the value of binpath. For most ports that require LaTeX that should satisfy the dependency, because it is written as bin:pdflatex:texlive-latex (e.g. if it needs the pdflatex binary) and bin:-style dependencies search in $PATH (which you've changed by editing the binpath setting).
For the cases where this doesn't help, please file bugs and request the Portfile be adjusted to allow MacTeX to satisfy the dependency.
I have: gstreamer-sdk, gstreamer-ffmpeg, gstreamer-plugins-good, bad, and ugly. I googled everywhere for this error and have found nothing relevant. I'm going a little nuts trying to figure out this error:
Error received from element decodebin20: Your GStreamer installation is missing a plug-in.
Debugging information: gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:playbin20/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20:
no suitable plugins found
It throws when I run my gstreamer program. Any ideas on why?
You may not be missing any plugins at all.
This error can be a result of just an unlinked pipeline.
Playbin2(decodebin2) got some changes that made it unable to automatically link up some pipelines that formally worked, for example transcoding a decoder to an encoder. In my case, explicitly adding the ffdec_h264 that it used to add automatically fixed it.
Relying on the Playbin2 can be very frustrating when it does not work. Using the setup below, you can create a .png diagram of the pipeline in various phases of construction. It's very helpful in finding why it isn't linking up.
export GST_DEBUG_DUMP_DOT_DIR=~/gstdump
for f in $GST_DEBUG_DUMP_DOT_DIR/*.dot ; do dot -T png $f >$f.png; done
This tool also lets you learn from it how to link up pipelines, and replace them with explicit ones that are easier to debug and less likely to break.
In Fedora, I resolved this issue removing gstreamer1-vaapi.x86_64:
sudo yum remove gstreamer1-vaapi.x86_64
uridecodebin is part of the "base" plugin set, so make sure you have gstreamer-plugins-base.
Another thing to look into is your LD_LIBRARY_PATH and GST_PLUGIN_PATH. If they point to a different GStreamer installation, it could cause problems like this. Also, if you didn't install GStreamer with a package manager, you may need to set your LD_LIBRARY_PATH to point to it (or better yet, install it with a package manager).
Pleas try to use gst-inspect command to find out if environment is correctly setup.
use gst-launch -v playbin2 uri = "your_uri_here" to find more information to trace this issue.