mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-14 05:12:09 +00:00
93ea284fe4
Original commit message from CVS: 2004-01-27 Ronald Bultje <rbultje@ronald.bitfreak.net> * docs/pwg/advanced_interfaces.xml: * docs/pwg/pwg.xml: Add as a placeholder for future filling-in. * docs/pwg/basics_autoplugging.xml: * docs/pwg/basics_buffers.xml: * docs/pwg/basics_elements.xml: * docs/pwg/basics_events.xml: * docs/pwg/basics_plugins.xml: * docs/pwg/basics_types.xml: Remove, because unused (this is all in intro_basics.xml). * docs/pwg/building_signals.xml: Short intro to signals + reference to GObject docs - we really shouldn't go into these sort of things to deply because we don't use them that extensively anyway. * docs/pwg/building_state.xml: Explanation of states. Benjamin, please check. * docs/pwg/building_testapp.xml: Put everything in one page - putting only a few lines of content per page doesn't really make sense. Time to get into the advanced topics. ;).
103 lines
4.3 KiB
XML
103 lines
4.3 KiB
XML
<!-- ############ chapter ############# -->
|
|
|
|
<chapter id="cha-building-testapp">
|
|
<title>Building a Test Application</title>
|
|
<para>
|
|
Often, you will want to test your newly written plugin in an as small
|
|
setting as possible. Ususally, <filename>gst-launch</filename> is a
|
|
good first step at testing a plugin. However, you will often need more
|
|
testing features than gst-launch can provide, such as seeking, events,
|
|
interactivity and more. Writing your own small testing program is the
|
|
easiest way to accomplish this. This section explains - in a few words
|
|
- how to do that. For a complete application development guide, see the
|
|
<ulink type="http" url="../manual/index.html">Application Development
|
|
Manual</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
At the start, you need to initialize the &GStreamer; core library by
|
|
calling <function>gst_init ()</function>. You can alternatively call
|
|
<function>gst_init_with_popt_tables ()</function>, which will return
|
|
a pointer to popt tables. You can then use libpopt to handle the
|
|
given argument table, and this will finish the &GStreamer; intialization.
|
|
</para>
|
|
|
|
<para>
|
|
You can create elements using <function>gst_element_factory_make ()</function>,
|
|
where the first argument is the element type that you want to create,
|
|
and the second argument is a free-form name. The example at the end uses
|
|
a simple filesource - decoder - soundcard output pipeline, but you can
|
|
use specific debugging elements if that's necessary. For example, an
|
|
<classname>identity</classname> element can be used in the middle of
|
|
the pipeline to act as a data-to-application transmitter. This can be
|
|
used to check the data for misbehaviours or correctness in your test
|
|
application. Also, you can use a <classname>fakesink</classname>
|
|
element at the end of the pipeline to dump your data to the stdout
|
|
(in order to do this, set the <function>dump</function> property to
|
|
TRUE). Lastly, you can use the <classname>efence</classname> element
|
|
(indeed, an eletric fence memory debugger wrapper element) to check
|
|
for memory errors.
|
|
</para>
|
|
|
|
<para>
|
|
During linking, your test application can use fixation or filtered caps
|
|
as a way to drive a specific type of data to or from your element. This
|
|
is a very simple and effective way of checking multiple types of input
|
|
and output in your element.
|
|
</para>
|
|
|
|
<para>
|
|
Running the pipeline happens through the <function>gst_bin_iterate ()</function>
|
|
function. Note that during running, you should connect to at least the
|
|
<quote>error</quote> and <quote>eos</quote> signals on the pipeline
|
|
and/or your plugin/element to check for correct handling of this. Also,
|
|
you should add events into the pipeline and make sure your plugin handles
|
|
these correctly (with respect to clocking, internal caching, etc.).
|
|
</para>
|
|
|
|
<para>
|
|
Never forget to clean up memory in your plugin or your test application.
|
|
When going to the NULL state, your element should clean up allocated
|
|
memory and caches. Also, it should close down any references held to
|
|
possible support libraries. Your application should <function>unref ()</function>
|
|
the pipeline and make sure it doesn't crash.
|
|
</para>
|
|
|
|
<programlisting>
|
|
#include <gst/gst.h>
|
|
|
|
gint
|
|
main (gint arcg,
|
|
gchar *argv[])
|
|
{
|
|
GstElement *pipeline, *filesrc, *decoder, *filter, *sink;
|
|
|
|
/* initialization */
|
|
gst_init (&argc, &argv);
|
|
|
|
/* create elements */
|
|
pipeline = gst_pipeline_new ("my_pipeline");
|
|
|
|
filesrc = gst_element_factory_make ("filesrc", "my_filesource");
|
|
decoder = gst_element_factory_make ("mad", "my_decoder");
|
|
filter = gst_element_factory_make ("my_filter", "my_filter");
|
|
sink = gst_element_factory_make ("osssink", "audiosink");
|
|
|
|
g_object_set (G_OBJECT (filesrc), "location", argv[1], NULL);
|
|
|
|
/* link everything together */
|
|
gst_element_link_many (filesrc, decoder, filter, sink, NULL);
|
|
gst_bin_add_many (GST_BIN (pipeline), filesrc, decoder, filter, sink, NULL);
|
|
|
|
/* run */
|
|
gst_element_set_state (pipeline, GST_STATE_PLAYING);
|
|
while (gst_bin_iterate (GST_BIN (pipeline)));
|
|
|
|
/* clean up */
|
|
gst_element_set_state (pipeline, GST_STATE_NULL);
|
|
gst_object_unref (GST_OBJECT (pipeline));
|
|
|
|
return 0;
|
|
}
|
|
</programlisting>
|
|
</chapter>
|