5564a1bbf40800760fede61080a38c98812a5818
[platform/upstream/gstreamer.git] / docs / gst / running.xml
1 <?xml version="1.0"?>
2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
3                "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
4 <!ENTITY % version-entities SYSTEM "version.entities">
5 %version-entities;
6 <!ENTITY % local.common.attrib "xmlns:xi  CDATA  #FIXED 'http://www.w3.org/2003/XInclude'">
7 ]>
8 <refentry id="gst-running" revision="08 Oct 2005">
9 <refmeta>
10 <refentrytitle>Running GStreamer Applications</refentrytitle>
11 <manvolnum>3</manvolnum>
12 <refmiscinfo>GStreamer Core</refmiscinfo>
13 </refmeta>
14
15 <refnamediv>
16 <refname>Running GStreamer Applications</refname>
17 <refpurpose>
18 How to run and debug your GStreamer application
19 </refpurpose>
20 </refnamediv>
21
22 <refsect1>
23 <title>Running and debugging GStreamer Applications</title>
24
25 <refsect2>
26 <title>Environment variables</title>
27
28 <para> 
29 GStreamer inspects a few of environment variables in addition to standard
30 variables like <envar>LANG</envar>, <envar>PATH</envar> or <envar>HOME</envar>. 
31 </para>
32
33 <formalpara id="GST_PLUGIN_SYSTEM_PATH">
34   <title><envar>GST_PLUGIN_SYSTEM_PATH</envar>,
35          <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar></title>
36
37   <para>
38
39 This environment variable can be set to a colon-separated list of paths.
40 If this variable is not set, GStreamer will fill in this list for you
41 with
42 <itemizedlist>
43   <listitem>
44     <para>
45 plug-ins in the user's home directory, or rather the user's "data home"
46 directory according to the xdg base dir specification. Usually this will be
47 a directory called
48 <filename>plugins</filename> inside the
49 <filename>.local/share/.gstreamer-&GST_API_VERSION;</filename> directory in
50 the user's home directory by default, though this search path may change if
51 the XDG_DATA_HOME environment variable is set.
52     </para>
53   </listitem>
54   <listitem>
55     <para>
56 plug-ins installed system-wide.  On this system, they are stored in
57 <filename>&GST_PLUGINS_DIR;</filename>.
58     </para>
59
60 </listitem>
61 </itemizedlist>
62    </para>
63
64     <para>
65 GStreamer will scan these paths for GStreamer plug-ins.  These plug-ins will
66 be loaded after the plug-ins in the GST_PLUGIN_PATH variable below.
67
68 The paths are scanned in the given order.  This allows a user to override
69 system-installed plug-ins with his own versions.
70    </para>
71   <para>
72 The GST_PLUGIN_SYSTEM_PATH_1_0 variant is useful if both the old GStreamer 0.10
73 version and the new GStreamer 1.0 version need to be pointed to new plugin
74 paths. The latter will use the _1_0 variant over the non-versioned one if
75 it is set.
76   </para>
77
78     <para>
79 Setting this variable to an empty string will cause GStreamer not to scan any
80 system paths at all for plug-ins.  This can be useful if you're running
81 uninstalled (for development purposes) or while running testsuites.
82    </para>
83
84 </formalpara>
85
86 <formalpara id="GST_PLUGIN_PATH">
87   <title><envar>GST_PLUGIN_PATH</envar>, <envar>GST_PLUGIN_PATH_1_0</envar></title>
88
89   <para>
90 This environment variable can be set to a colon-separated list of paths.
91 GStreamer will scan these paths for GStreamer plug-ins.  These plug-ins will
92 be loaded in addition to, and before, the plug-ins in the system paths.
93   </para>
94   <para>
95 The GST_PLUGIN_PATH_1_0 variant is useful if both the old GStreamer 0.10
96 version and the new GStreamer 1.0 version need to be pointed to new plugin
97 paths. The latter will use the _1_0 variant over the non-versioned one if
98 it is set.
99   </para>
100 </formalpara>
101
102 <formalpara id="GST_DEBUG">
103   <title><envar>GST_DEBUG</envar></title>
104
105   <para>
106 If GStreamer has been configured with <option>--enable-gst-debug=yes</option>,
107 this variable can be set to a list of debug options, which cause GStreamer
108 to print out different types of debugging information to stderr.
109   </para>
110   <para>
111 The variable takes a comma-separated list of "category_name:level" pairs
112 to set specific levels for the individual categories.
113 The level value ranges from 0 (nothing) to 9 (MEMDUMP).
114     <variablelist>
115
116       <varlistentry>
117         <term>1 - <option>ERROR</option></term>
118         <listitem>
119 <para>
120 Logs all fatal errors.  These are errors that do not allow the core or elements
121 to perform the requested action.  The application can still recover if
122 programmed to handle the conditions that triggered the error.
123 </para>
124         </listitem>
125       </varlistentry>
126
127       <varlistentry>
128         <term>2 - <option>WARNING</option></term>
129         <listitem>
130 <para>
131 Logs all warnings.  Typically these are non-fatal, but user-visible problems
132 are expected to happen.
133 </para>
134         </listitem>
135       </varlistentry>
136
137       <varlistentry>
138         <term>3 - <option>FIXME</option></term>
139         <listitem>
140 <para>
141 Logs all fixme messages. Fixme messages are messages that indicate that something
142 in the executed code path is not fully implemented or handled yet.  The purpose
143 of this message is to make it easier to spot incomplete/unfinished pieces of
144 code when reading the debug log.
145 </para>
146         </listitem>
147       </varlistentry>
148
149       <varlistentry>
150         <term>4 - <option>INFO</option></term>
151         <listitem>
152 <para>
153 Logs all informational messages.  These are typically used for events in
154 the system that only happen once, or are important and rare enough to be
155 logged at this level.
156 </para>
157         </listitem>
158       </varlistentry>
159
160       <varlistentry>
161         <term>5 - <option>DEBUG</option></term>
162         <listitem>
163 <para>
164 Logs all debug messages.  These are general debug messages for events
165 that happen only a limited number of times during an object's lifetime;
166 these include setup, teardown, change of parameters, ...
167 </para>
168         </listitem>
169       </varlistentry>
170
171       <varlistentry>
172         <term>6 - <option>LOG</option></term>
173         <listitem>
174 <para>
175 Logs all log messages.  These are messages for events
176 that happen repeatedly during an object's lifetime;
177 these include streaming and steady-state conditions.
178 </para>
179         </listitem>
180       </varlistentry>
181
182       <varlistentry>
183         <term>7 - <option>TRACE</option></term>
184         <listitem>
185 <para>
186 Logs all trace messages.  These messages for events
187 that happen repeatedly during an object's lifetime such as the
188 ref/unref cycles.
189 </para>
190         </listitem>
191       </varlistentry>
192
193       <varlistentry>
194         <term>9 - <option>MEMDUMP</option></term>
195         <listitem>
196 <para>
197 Log all memory dump messages. Memory dump messages are used to log
198 (small) chunks of data as memory dumps in the log. They will be displayed
199 as hexdump with ASCII characters.
200 </para>
201         </listitem>
202       </varlistentry>
203     </variablelist>
204
205  The category_name can contain "<option>*"</option> as a wildcard.
206   </para>
207
208   <para>
209 For example, setting <envar>GST_DEBUG</envar> to
210 <option>GST_AUTOPLUG:6,GST_ELEMENT_*:4</option>, will cause the
211 <option>GST_AUTOPLUG</option> category to be logged at full
212 <option>LOG</option> level, while all categories starting with
213 <option>GST_ELEMENT_</option> will be logged at <option>INFO</option> level.
214   </para>
215
216   <para>
217 To get all possible debug output, set
218 <envar>GST_DEBUG</envar>
219 to <option>*:9</option>. For debugging purposes a <option>*:6</option> debug
220 log is usually the most useful, as it contains all important information, but
221 hides a lot of noise such as refs/unrefs. For bug reporting purposes, a
222 <option>*:6</option> log is also what will be requested usually. It's often
223 also worth running with <option>*:3</option> to see if there are any
224 non-fatal errors or warnings that might be related to the problem at hand.
225   </para>
226
227   <para>
228 Since GStreamer 1.2 it is also possible to specify debug levels by name,
229 e.g. GST_DEBUG=*:WARNING,*audio*:LOG
230   </para>
231
232 </formalpara>
233
234 <formalpara id="GST_DEBUG_NO_COLOR">
235   <title><envar>GST_DEBUG_NO_COLOR</envar></title>
236
237   <para>
238 Set this environment variable to any value ("1" typically) to switch off
239 colouring in GST_DEBUG output. This has the same effect as specifying the
240 <option>--gst-debug-no-color</option> command line option to well-behaved
241 GStreamer applications (ie. those that pass command-line options correctly to
242 GStreamer).
243 This is particularly useful to reduce the size of debug output and also allows
244 for the output to be compressed much better than with colours turned on.
245   </para>
246
247 </formalpara>
248
249 <formalpara id="GST_DEBUG_OPTIONS">
250   <title><envar>GST_DEBUG_OPTIONS</envar></title>
251
252   <para>
253 This environment variable can be used to tweak the behaviour of the debugging
254 system. Currently the only options supported are "pretty-tags" and "full-tags".
255 In "pretty-tags" mode (the default), taglists in the debug log will be
256 serialized so that only the first few and last few bytes of a buffer-type tag
257 will be serialized into the log, to avoid dumping hundreds of lines of useless
258 output into the log in case of large image tags and the like.
259   </para>
260
261 </formalpara>
262
263 <formalpara id="GST_DEBUG_DUMP_DOT_DIR">
264   <title><envar>GST_DEBUG_DUMP_DOT_DIR</envar></title>
265
266   <para>
267 Set this environment variable to a path to turn on all
268 #GST_DEBUG_BIN_TO_DOT_FILE or #GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS calls
269 and have the dot files in that location.
270   </para>
271   <para>
272 This will only work if the application in question makes these calls in
273 strategic places (like when the pipeline state changes or an error occurs).
274 gst-launch-&GST_API_VERSION; is one such application.
275   </para>
276   <para>
277 These .dot files can then be turned into images using the 'dot' utility
278 from the graphviz set of tools, like this:
279   <command>dot foo.dot -Tsvg -o foo.svg</command> or
280   <command>dot foo.dot -Tpng -o foo.png</command> or
281   <command>dot foo.dot -Tjpg -o foo.jpg</command>.
282   </para>
283
284 </formalpara>
285
286 <formalpara id="GST_REGISTRY">
287   <title><envar>GST_REGISTRY</envar>, <envar>GST_REGISTRY_1_0</envar></title>
288
289   <para>
290 Set this environment variable to make GStreamer use a different file for the
291 plugin cache / registry than the default one. This is useful when operating
292 in a separate environment which should not affect the default cache in the
293 user's home directory.
294   </para>
295
296 </formalpara>
297
298 <formalpara id="GST_REGISTRY_FORK">
299   <title><envar>GST_REGISTRY_FORK</envar></title>
300
301   <para>
302 Set this environment variable to "no" to prevent GStreamer from forking on
303 startup in order to update the plugin registry. This is useful for debugging
304 purposes, but should not be used under normal circumstances, since it means
305 that plugins may be loaded into memory even if they are not needed by the
306 application.
307   </para>
308
309 </formalpara>
310
311 <formalpara id="GST_REGISTRY_UPDATE">
312   <title><envar>GST_REGISTRY_UPDATE</envar></title>
313
314   <para>
315 Set this environment variable to "no" to prevent GStreamer from updating the
316 plugin registry. This is useful for embedded device which is not updating the
317 plugins frequently, it will save time when doing gst_init().
318   </para>
319
320 </formalpara>
321
322 <formalpara id="GST_TRACE">
323   <title><envar>GST_TRACE</envar></title>
324
325   <para>
326     Enable memory allocation tracing. Most GStreamer objects have support for
327     tracing the number of unfreed objects and their memory pointers.
328   </para>
329   <para>
330 The variable takes a comma-separated list of tracing options to enable.
331     <variablelist>
332
333       <varlistentry>
334         <term>live</term>
335         <listitem>
336 <para>
337   Counts all live objects and dumps an overview of the number of unfreed
338   objects at program exit.
339 </para>
340         </listitem>
341       </varlistentry>
342
343       <varlistentry>
344         <term>mem-live</term>
345         <listitem>
346 <para>
347   Keep track of the unfreed memory pointers and dump an overview of all unfreed
348   memory at program exit. Together with a level 9 debug log this can be used to
349   follow the lifecycle of leaked objects in order to track down where they are
350   leaked. This can be useful for debugging memory leaks in situations where
351   tools such as valgrind are not available, or not an option.
352 </para>
353         </listitem>
354       </varlistentry>
355     </variablelist>
356
357  Use <option>all</option> to enable all tracing flags.
358   </para>
359 </formalpara>
360
361 <formalpara id="GST_DEBUG_FILE">
362   <title><envar>GST_DEBUG_FILE</envar></title>
363
364   <para>
365   Set this variable to a file path to redirect all GStreamer debug
366   messages to this file. If left unset, debug messages with be output
367   unto the standard error.
368   </para>
369
370 </formalpara>
371
372 <formalpara id="ORC_CODE">
373   <title><envar>ORC_CODE</envar></title>
374
375   <para>
376 Useful Orc environment variable. Set ORC_CODE=debug to enable debuggers
377 such as gdb to create useful backtraces from Orc-generated code.  Set
378 ORC_CODE=backup or ORC_CODE=emulate if you suspect Orc's SIMD code
379 generator is producing incorrect code (Quite a few important
380 GStreamer plugins like videotestsrc, audioconvert or audioresample use Orc).
381 One can also combine flags like ORC_CODE=backup,debug.
382   </para>
383
384 </formalpara>
385
386 <formalpara id="G_DEBUG">
387   <title><envar>G_DEBUG</envar></title>
388
389   <para>
390 Useful GLib environment variable. Set G_DEBUG=fatal_warnings to make
391 GStreamer programs abort when a critical warning such as an assertion failure
392 occurs. This is useful if you want to find out which part of the code caused
393 that warning to be triggered and under what circumstances. Simply set G_DEBUG
394 as mentioned above and run the program in gdb (or let it core dump). Then get
395 a stack trace in the usual way.
396   </para>
397
398 </formalpara>
399
400 <formalpara id="G_SLICE">
401   <title><envar>G_SLICE</envar></title>
402
403   <para>
404 Useful GLib environment variable. Set G_SLICE=always-malloc when running
405 GStreamer programs in valgrind, or debugging memory leaks with other tools.
406 See the GLib API reference for more details.
407   </para>
408
409 </formalpara>
410
411 </refsect2>
412
413 </refsect1>
414
415 </refentry>