mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-28 04:31:06 +00:00
104 lines
4.2 KiB
Markdown
104 lines
4.2 KiB
Markdown
# Troubleshooting GStreamer
|
|
|
|
## 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
|
|
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
|
|
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
|
|
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.
|
|
|
|
## The GStreamer application I used stops with a segmentation fault. What can I do ?
|
|
|
|
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).
|
|
|