gstreamer/subprojects/gst-docs/markdown/frequently-asked-questions/troubleshooting.md

104 lines
4.2 KiB
Markdown
Raw Normal View History

# Troubleshooting GStreamer
## What should I do if I'm missing a plug-in?
*Some application is telling me that I am missing a plug-in. What do I do?*
Well, start by checking if you really are missing the plug-in.
```
gst-inspect-1.0 (plug-in)
```
and replace (plug-in) with the plug-in you think is missing. If this
2016-11-15 11:05:34 +00:00
doesn't return any result, then you either don't have it or it can't be
found (which can easily happen if you have installed things from source).
If you're not sure either way, then chances are good that you don't have
2016-11-15 11:05:34 +00:00
it. You should get the plug-in and restart the application. How
to get the plug-in depends on your distribution. Many applications
and distributions nowadays support automatic plugin installation of
missing plugins. Mayb also try playing your file with a different application
if your application does not support installation of missing plugins.
- if you run GStreamer using packages for your distribution, you
should check what packages are available for your distribution and
2016-11-15 11:05:34 +00:00
see if any of the available packages contains the plug-in. Make sure
you have the common plugin packages installed, such as gst-plugins-base,
gst-plugins-good, gst-plugins-ugly, gst-plugins-bad, and gst-libav.
- if you run GStreamer from a source install, there's a good chance
the plug-in didn't get built because you are missing an external
library. When you ran configure, you should have gotten output of
what plug-ins are going to be built. You can re-run configure to see
if it's there. If it isn't, there is a good reason why it is not
getting built. The most likely is that you're missing the library
you need for it. Check the README file in gst-plugins to see what
library you need. Make sure to remember to re-run configure after
installing the supporting library \!
- if you run GStreamer from git, the same logic applies as for a
source install. Go over the reasons why the plug-in didn't get
configured for build. Check output of config.log for a clue as to
why it doesn't get built if you're sure you have the library needed
installed in a sane place.
## What can I do if I get a segmentation fault?
*The GStreamer application I used stops with a segmentation fault. What can I do?*
2016-11-15 11:05:34 +00:00
The first point of contact for any problems with a GStreamer application
should be the developers of that application. They will be able to investigate
whether the problem lies with the application or with GStreamer, and will pass
on any issues to GStreamer developers if needed.
There are two things you can do. If you compiled GStreamer with
specific optimization compilation flags, you should try recompiling
GStreamer, the application and the plug-ins without any optimization
flags. This allows you to verify if the problem is due to optimization
or due to bad code. Second, it will also allow you to provide a
reasonable backtrace in case the segmentation fault still occurs.
The second thing you can do is look at the backtrace to get an idea of
where things are going wrong, or give us an idea of what is going wrong.
To provide a backtrace, you should
1. run the application in gdb by starting it with
```
gdb (gst-application)
```
(If the application is in a source tree instead of installed on the
system, you might want to put "libtool" before "gdb")
2. Pass on the command line arguments to the application by typing
```
set args (the arguments to the application)
```
at the (gdb) prompt
3. Type "run" at the (gdb) prompt and wait for the application to
segfault. The application will run a lot slower, however.
4. After the segfault, type "bt" to get a backtrace. This is a stack of
function calls detailing the path from main () to where the code is
currently at.
5. If the application you're trying to debug contains threads, it is
also useful to do
```
info threads
```
and get backtraces of all of the threads involved, by switching to a
different thread using "thread (number)" and then again requesting a
backtrace using "bt".
6. If you can't or don't want to work out the problem yourself, a copy
and paste of all this information should be included in your [bug
report](#using-bugs-where).