without needing any adaptations to its autopluggers.
</para>
<para>
- We will first introduce the concept of MIME types as a dynamic and
+ We will first introduce the concept of Media types as a dynamic and
extendible way of identifying media streams. After that, we will introduce
the concept of typefinding to find the type of a media stream. Lastly,
we will explain how autoplugging and the &GStreamer; registry can be
- used to setup a pipeline that will convert media from one mimetype to
+ used to setup a pipeline that will convert media from one mediatype to
another, for example for media decoding.
</para>
- <sect1 id="section-mime">
- <title>MIME-types as a way to identify streams</title>
+ <sect1 id="section-media">
+ <title>Media types as a way to identify streams</title>
<para>
We have previously introduced the concept of capabilities as a way
for elements (or, rather, pads) to agree on a media type when
streaming data from one element to the next (see <xref
linkend="section-caps"/>). We have explained that a capability is
- a combination of a mimetype and a set of properties. For most
+ a combination of a media type and a set of properties. For most
container formats (those are the files that you will find on your
hard disk; Ogg, for example, is a container format), no properties
- are needed to describe the stream. Only a MIME-type is needed. A
- full list of MIME-types and accompanying properties can be found
+ are needed to describe the stream. Only a media type is needed. A
+ full list of media types and accompanying properties can be found
in <ulink type="http"
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-types-definitions.html">the
Plugin Writer's Guide</ulink>.
</para>
<para>
- An element must associate a MIME-type to its source and sink pads
+ An element must associate a media type to its source and sink pads
when it is loaded into the system. &GStreamer; knows about the
different elements and what type of data they expect and emit through
the &GStreamer; registry. This allows for very dynamic and extensible
<para>
In <xref linkend="chapter-helloworld"/>, we've learned to build a
- music player for Ogg/Vorbis files. Let's look at the MIME-types
+ music player for Ogg/Vorbis files. Let's look at the media types
associated with each pad in this pipeline. <xref
- linkend="section-mime-img"/> shows what MIME-type belongs to each
+ linkend="section-mime-img"/> shows what media type belongs to each
pad in this pipeline.
</para>
<figure float="1" id="section-mime-img">
- <title>The Hello world pipeline with MIME types</title>
+ <title>The Hello world pipeline with media types</title>
<mediaobject>
<imageobject>
<imagedata scale="75" fileref="images/mime-world.ℑ" format="&IMAGE;"/>
<para>
Plugins in &GStreamer; can, as mentioned before, implement typefinder
functionality. A plugin implementing this functionality will submit
- a mimetype, optionally a set of file extensions commonly used for this
+ a media type, optionally a set of file extensions commonly used for this
media type, and a typefind function. Once this typefind function inside
the plugin is called, the plugin will see if the data in this media
stream matches a specific pattern that marks the media type identified
- by that mimetype. If it does, it will notify the typefind element of
+ by that media type. If it does, it will notify the typefind element of
this fact, telling which mediatype was recognized and how certain we
are that this stream is indeed that mediatype. Once this run has been
completed for all plugins implementing a typefind functionality, the
the registry that can decode this streamtype. For this, we will get
all element factories (which we've seen before in <xref
linkend="section-elements-create"/>) and find the ones with the
- given MIME-type and capabilities on their sinkpad. Note that we will
+ given media type and capabilities on their sinkpad. Note that we will
only use parsers, demuxers and decoders. We will not use factories for
any other element types, or we might get into a loop of encoders and
decoders. For this, we will want to build a list of <quote>allowed</quote>
GstCaps *caps)
{
GstObject *parent = GST_OBJECT (GST_OBJECT_PARENT (pad));
- const gchar *mime;
+ const gchar *media;
const GList *item;
GstCaps *res, *audiocaps;
}
/* as said above, we only try to plug audio... Omit video */
- mime = gst_structure_get_name (gst_caps_get_structure (caps, 0));
- if (g_strrstr (mime, "video")) {
- g_print ("Omitting link for pad %s:%s because mimetype %s is non-audio\n",
- GST_OBJECT_NAME (parent), GST_OBJECT_NAME (pad), mime);
+ media = gst_structure_get_name (gst_caps_get_structure (caps, 0));
+ if (g_strrstr (media, "video")) {
+ g_print ("Omitting link for pad %s:%s because media type %s is non-audio\n",
+ GST_OBJECT_NAME (parent), GST_OBJECT_NAME (pad), media);
return;
}
/* if we get here, no item was found */
g_print ("No compatible pad found to decode %s on %s:%s\n",
- mime, GST_OBJECT_NAME (parent), GST_OBJECT_NAME (pad));
+ media, GST_OBJECT_NAME (parent), GST_OBJECT_NAME (pad));
}
static void
<title>Data probing</title>
<para>
Probing is best envisioned as a pad listener. Technically, a probe is
- nothing more than a signal callback that can be attached to a pad.
- Those signals are by default not fired at all (since that may have a
- negative impact on performance), but can be enabled by attaching a
- probe using <function>gst_pad_add_buffer_probe ()</function>,
- <function>gst_pad_add_event_probe ()</function>, or
- <function>gst_pad_add_data_probe ()</function>.
- Those functions attach the signal handler and
- enable the actual signal emission. Similarly, one can use the
- <function>gst_pad_remove_buffer_probe ()</function>,
- <function>gst_pad_remove_event_probe ()</function>, or
- <function>gst_pad_remove_data_probe ()</function>
- to remove the signal handlers again.
+ nothing more than a callback that can be attached to a pad.
+ You can attach a probe using <function>gst_pad_add_probe ()</function>.
+ Similarly, one can use the
+ <function>gst_pad_remove_probe ()</function>
+ to remove the callback again.
</para>
<para>
Probes run in pipeline threading context, so callbacks should try to
<programlisting><!-- example-begin probe.c -->
#include <gst/gst.h>
-static gboolean
-cb_have_data (GstPad *pad,
- GstBuffer *buffer,
- gpointer u_data)
+static GstPadProbeReturn
+cb_have_data (GstPad *pad,
+ GstPadProbeInfo *info,
+ gpointer user_data)
{
gint x, y;
- GstMapInfo info;
+ GstMapInfo map;
guint16 *ptr, t;
+ GstBuffer *buffer;
+
+ buffer = GST_PAD_PROBE_INFO_BUFFER (info);
- gst_buffer_map (buffer, &info, GST_MAP_WRITE);
+ gst_buffer_map (buffer, &map, GST_MAP_WRITE);
- ptr = info.data;
+ ptr = (guint16 *) map.data;
/* invert data */
for (y = 0; y < 288; y++) {
for (x = 0; x < 384 / 2; x++) {
}
ptr += 384;
}
- gst_buffer_unmap (buffer, &info);
+ gst_buffer_unmap (buffer, &map);
return TRUE;
}
g_object_set (G_OBJECT (filter), "caps", filtercaps, NULL);
gst_caps_unref (filtercaps);
- pad = gst_element_get_pad (src, "src");
- gst_pad_add_buffer_probe (pad, G_CALLBACK (cb_have_data), NULL);
+ pad = gst_element_get_static_pad (src, "src");
+ gst_pad_add_probe (pad, GST_PAD_PROBE_TYPE_BUFFER,
+ (GstPadProbeCallback) cb_have_data, NULL, NULL);
gst_object_unref (pad);
/* run */
<para>
The above example is not really correct though. Strictly speaking, a
pad probe callback is only allowed to modify the buffer content if the
- buffer is writable, and it is only allowed to modify buffer metadata like
- timestamps, caps, etc. if the buffer metadata is writable. Whether this
- is the case or not depends a lot on the pipeline and the elements
- involved. Often enough, this is the case, but sometimes it is not,
- and if it is not then unexpected modification of the data or metadata
- can introduce bugs that are very hard to debug and track down. You can
- check if a buffer and its metadata are writable with
- <function>gst_buffer_is_writable ()</function> and
- <function>gst_buffer_is_metadata_writable ()</function>. Since you
- can't pass back a different buffer than the one passed in, there is no
- point of making a buffer writable in the callback function.
+ buffer is writable. Whether this is the case or not depends a lot on
+ the pipeline and the elements involved. Often enough, this is the case,
+ but sometimes it is not, and if it is not then unexpected modification
+ of the data or metadata can introduce bugs that are very hard to debug
+ and track down. You can check if a buffer is writable with
+ <function>gst_buffer_is_writable ()</function>. Since you
+ can pass back a different buffer than the one passed in, it is a good
+ idea to make the buffer writable in the callback function.
</para>
<para>
Pad probes are suited best for looking at data as it passes through
contains an initialization function (usually called
<function>plugin_init</function>) that will be called right after that.
It's purpose is to register the elements provided by the plugin with
- the &GStreamer; framework. If you want to embed elements directly in
+ the &GStreamer; framework.
+ If you want to embed elements directly in
your application, the only thing you need to do is to replace
- <function>GST_PLUGIN_DEFINE ()</function> with
- <function>GST_PLUGIN_DEFINE_STATIC ()</function>. This will cause the
- elements to be registered when your application loads, and the elements
+ <function>GST_PLUGIN_DEFINE ()</function> with a call to
+ <function>gst_plugin_register_static ()</function>. As soon as you
+ call <function>gst_plugin_register_static ()</function>, the elements
will from then on be available like any other element, without them
having to be dynamically loadable libraries. In the example below, you
would be able to call <function>gst_element_factory_make
GST_RANK_NONE, MY_PLUGIN_TYPE);
}
-GST_PLUGIN_DEFINE_STATIC (
- GST_VERSION_MAJOR,
- GST_VERSION_MINOR,
- "my-private-plugins",
- "Private elements of my application",
- register_elements,
- VERSION,
- "LGPL",
- "my-application",
- "http://www.my-application.net/"
-)
+static
+my_code_init (void)
+{
+ ...
+
+ gst_plugin_register_static (
+ GST_VERSION_MAJOR,
+ GST_VERSION_MINOR,
+ "my-private-plugins",
+ "Private elements of my application",
+ register_elements,
+ VERSION,
+ "LGPL",
+ "my-application-source",
+ "my-application",
+ "http://www.my-application.net/")
+
+ ...
+}
</programlisting>
</sect1>
</chapter>
</para>
</sect1>
- <sect1 id="section-interfaces-mixer">
- <title>The Mixer interface</title>
-
- <para>
- The mixer interface provides a uniform way to control the volume on a
- hardware (or software) mixer. The interface is primarily intended to
- be implemented by elements for audio inputs and outputs that talk
- directly to the hardware (e.g. OSS or ALSA plugins).
- </para>
- <para>
- Using this interface, it is possible to control a list of tracks
- (such as Line-in, Microphone, etc.) from a mixer element. They can
- be muted, their volume can be changed and, for input tracks, their
- record flag can be set as well.
- </para>
- <para>
- Example plugins implementing this interface include the OSS elements
- (osssrc, osssink, ossmixer) and the ALSA plugins (alsasrc, alsasink
- and alsamixer).
- </para>
- <para>
- You should not use this interface for volume control in a playback
- application. Either use a <classname>volume</classname> element or use
- <classname>playbin</classname>'s <quote>volume</quote> property, or use
- the <classname>audiosink</classname>'s <quote>volume</quote> property (if it has one).
- </para>
- <note>
- <para>
- In order for the <ulink type="http"
- url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstmixer.html"><classname>GstMixer</classname></ulink>
- interface to be
- usable, the element implementing it needs to be in the right state,
- so that the underlying mixer device is open. This usually means the
- element needs to be at least in <classname>GST_STATE_READY</classname>
- before you can use this interface. You will get confusing warnings
- if the element is not in the right state when the interface is used.
- </para>
- </note>
- </sect1>
-
- <sect1 id="section-interfaces-tuner">
- <title>The Tuner interface</title>
-
- <para>
- The tuner interface is a uniform way to control inputs and outputs
- on a multi-input selection device. This is primarily used for input
- selection on elements for TV- and capture-cards.
- </para>
- <para>
- Using this interface, it is possible to select one track from a list
- of tracks supported by that tuner-element. The tuner will then select
- that track for media-processing internally. This can, for example, be
- used to switch inputs on a TV-card (e.g. from Composite to S-video).
- </para>
- <para>
- This interface is currently only implemented by the Video4linux and
- Video4linux2 elements.
- </para>
- <note>
- <para>
- In order for the <ulink type="http"
- url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gsttuner.html"><classname>GstTuner</classname></ulink>
- interface to be
- usable, the element implementing it needs to be in the right state,
- so that the underlying device is open. This usually means the
- element needs to be at least in <classname>GST_STATE_READY</classname>
- before you can use this interface. You will get confusing warnings
- if the element is not in the right state when the interface is used.
- </para>
- </note>
- </sect1>
-
<sect1 id="section-interfaces-colorbalance">
<title>The Color Balance interface</title>
</para>
<para>
The colorbalance interface is implemented by several plugins, including
- xvimagesink and the Video4linux and Video4linux2 elements.
- </para>
- </sect1>
-
- <sect1 id="section-interfaces-proprobe">
- <title>The Property Probe interface</title>
-
- <para>
- The property probe is a way to autodetect allowed values for a
- <classname>GObject</classname> property. It's primary use is to autodetect
- devices in several elements. For example, the OSS elements use this
- interface to detect all OSS devices on a system. Applications can then
- <quote>probe</quote> this property and get a list of detected devices.
- </para>
- <note>
- <para>
- Given the overlap between HAL and the practical implementations of this
- interface, this might in time be deprecated in favour of HAL.
- </para>
- </note>
- <para>
- This interface is currently implemented by many elements, including
- the ALSA, OSS, XVideo, Video4linux and Video4linux2 elements.
+ xvimagesink and the Video4linux2 elements.
</para>
</sect1>
- <sect1 id="section-interfaces-xoverlay">
- <title>The X Overlay interface</title>
+ <sect1 id="section-interfaces-videooverlay">
+ <title>The Video Overlay interface</title>
<para>
- The X Overlay interface was created to solve the problem of embedding
+ The Video Overlay interface was created to solve the problem of embedding
video streams in an application window. The application provides an
- X-window to the element implementing this interface to draw on, and
- the element will then use this X-window to draw on rather than creating
+ window handle to the element implementing this interface to draw on, and
+ the element will then use this window handle to draw on rather than creating
a new toplevel window. This is useful to embed video in video players.
</para>
<para>
- This interface is implemented by, amongst others, the Video4linux and
- Video4linux2 elements and by ximagesink, xvimagesink and sdlvideosink.
+ This interface is implemented by, amongst others, the Video4linux2
+ elements and by ximagesink, xvimagesink and sdlvideosink.
</para>
</sect1>
</chapter>
<title>Scheduling in &GStreamer;</title>
<para>
- Scheduling of pipelines in &GStreamer; is done by using a thread for
- each <quote>group</quote>, where a group is a set of elements separated
- by <quote>queue</quote> elements. Within such a group, scheduling is
- either push-based or pull-based, depending on which mode is supported
- by the particular element. If elements support random access to data,
- such as file sources, then elements downstream in the pipeline become
- the entry point of this group (i.e. the element controlling the
- scheduling of other elements). The entry point pulls data from upstream
- and pushes data downstream, thereby calling data handling functions on
- either type of element.
+ Each element in the &GStreamer; pipeline decides how it is going to
+ be scheduled. Elements can choose to be scheduled push-based or
+ pull-based.
+ If elements support random access to data, such as file sources,
+ then elements downstream in the pipeline can ask to schedule the random
+ access elements in pull-based mode. Data is pulled from upstream
+ and pushed downstream. If pull-mode is not supported, the element can
+ decide to operate in push-mode.
</para>
<para>
In practice, most elements in &GStreamer;, such as decoders, encoders,
For example, <option>--gst-debug=oggdemux:5</option> would turn
on debugging for the Ogg demuxer element. You can use wildcards as
well. A debugging level of 0 will turn off all debugging, and a level
- of 5 will turn on all debugging. Intermediate values only turn on
+ of 9 will turn on all debugging. Intermediate values only turn on
some debugging (based on message severity; 2, for example, will only
display errors and warnings). Here's a list of all available options:
</para>
</para>
</sect2>
- <sect2 id="section-applications-gst-editor">
- <title>GstEditor</title>
- <para>
- GstEditor is a set of widgets to display a graphical representation of a
- pipeline.
- </para>
- </sect2>
-
</sect1>
</chapter>
<para>
For audio input and output, &GStreamer; provides input and
output elements for several audio subsystems. Amongst others,
- &GStreamer; includes elements for ALSA (alsasrc, alsamixer,
- alsasink), OSS (osssrc, ossmixer, osssink) and Sun audio
- (sunaudiosrc, sunaudiomixer, sunaudiosink).
+ &GStreamer; includes elements for ALSA (alsasrc,
+ alsasink), OSS (osssrc, osssink) Pulesaudio (pulsesrc, pulsesink)
+ and Sun audio (sunaudiosrc, sunaudiomixer, sunaudiosink).
</para>
</listitem>
<listitem>
<para>
For video input, &GStreamer; contains source elements for
- Video4linux (v4lsrc, v4lmjpegsrc, v4lelement and v4lmjpegisnk)
- and Video4linux2 (v4l2src, v4l2element).
+ Video4linux2 (v4l2src, v4l2element, v4l2sink).
</para>
</listitem>
<listitem>
</itemizedlist>
</sect1>
</chapter>
+<chapter id="chapter-porting-1.0">
+ <title>Porting 0.10 applications to 1.0</title>
+ <para>
+ This section of the appendix will discuss shortly what changes to
+ applications will be needed to quickly and conveniently port most
+ applications from &GStreamer;-0.10 to &GStreamer;-1.0, with references
+ to the relevant sections in this Application Development Manual
+ where needed. With this list, it should be possible to port simple
+ applications to &GStreamer;-1.0 in less than a day.
+ </para>
+
+ <sect1 id="section-porting-objects-1.0">
+ <title>List of changes</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ All deprecated methods were removed. Recompile against 0.10 with
+ DISABLE_DEPRECATED and fix issues before attempting to port to 1.0.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ "playbin2" has been renamed to "playbin", with similar API
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ "decodebin2" has been renamed to "decodebin", with similar API. Note
+ that there is no longer a "new-decoded-pad" signal, just use GstElement's
+ "pad-added" signal instead (but don't forget to remove the 'gboolean last'
+ argument from your old signal callback functino signature).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ the names of some "formatted" pad templates has been changed from e.g.
+ "src%d" to "src%u" or "src_%u" or similar, since we don't want to see
+ negative numbers in pad names. This mostly affects applications that
+ create request pads from elements.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ some elements that used to have a single dynamic source pad have a
+ source pad now. Example: wavparse, id3demux, iceydemux, apedemux.
+ (This does not affect applications using decodebin or playbin).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ playbin now proxies the GstVideoOverlay (former GstXOverlay) interface,
+ so most applications can just remove the sync bus handler where they
+ would set the window ID, and instead just set the window ID on playbin
+ from the application thread before starting playback.
+ </para>
+ <para>
+ playbin also proxies the GstColorBalance and GstNavigation interfaces,
+ so applications that use this don't need to go fishing for elements
+ that may implement those any more, but can just use them unconditionally.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ multifdsink, tcpclientsink, tcpclientsrc, tcpserversrc the protocol property
+ is removed, use gdppay and gdpdepay.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ XML serialization was removed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Probes and pad blocking was merged into new pad probes.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Position, duration and convert functions no longer use an inout parameter
+ for the destination format.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Video and audio caps were simplified. audio/x-raw-int and audio/x-raw-float
+ are now all under the audio/x-raw media type. Similarly, video/x-raw-rgb
+ and video/x-raw-yuv are now video/x-raw.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ ffmpegcolorspace was removed and replaced with videoconvert.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GstMixerInterface / GstTunerInterface were removed without replacement.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The GstXOverlay interface was renamed to GstVideoOverlay, and now part
+ of the video library in gst-plugins-base, as the interfaces library
+ no longer exists.
+ </para>
+ <para>
+ The name of the GstXOverlay "prepare-xwindow-id" message has changed
+ to "prepare-window-handle" (and GstXOverlay has been renamed to
+ GstVideoOverlay). Code that checks for the string directly should be
+ changed to use gst_is_video_overlay_prepare_window_handle_message(message)
+ instead.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The GstPropertyProbe interface was removed. the is no replacement yet,
+ but a more featureful replacement for device discovery and feature
+ querying is planned, see https://bugzilla.gnome.org/show_bug.cgi?id=678402
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ gst_uri_handler_get_uri() and the get_uri vfunc now return a copy of
+ the URI string
+ </para>
+ <para>
+ gst_uri_handler_set_uri() and the set_uri vfunc now take an additional
+ GError argument so the handler can notify the caller why it didn't
+ accept a particular URI.
+ </para>
+ <para>
+ gst_uri_handler_set_uri() now checks if the protocol of the URI passed
+ is one of the protocols advertised by the uri handler, so set_uri vfunc
+ implementations no longer need to check that as well.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GstTagList is now an opaque mini object instead of being typedefed to a
+ GstStructure. While it was previously okay (and in some cases required because of
+ missing taglist API) to cast a GstTagList to a GstStructure or use
+ gst_structure_* API on taglists, you can no longer do that. Doing so will
+ cause crashes.
+ </para>
+ <para>
+ Also, tag lists are refcounted now, and can therefore not be freely
+ modified any longer. Make sure to call gst_tag_list_make_writable (taglist)
+ before adding, removing or changing tags in the taglist.
+ </para>
+ <para>
+ GST_TAG_IMAGE, GST_TAG_PREVIEW_IMAGE, GST_TAG_ATTACHMENT: many tags that
+ used to be of type GstBuffer are now of type GstSample (which is basically
+ a struct containing a buffer alongside caps and some other info).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GstController has now been merged into GstObject. It does not exists as an
+ individual object anymore. In addition core contains a GstControlSource base
+ class and the GstControlBinding. The actual control sources are in the controller
+ library as before. The 2nd big change is that control sources generate
+ a sequence of gdouble values and those are mapped to the property type and
+ value range by GstControlBindings.
+ </para>
+ <para>
+ The whole gst_controller_* API is gone and now available in simplified form
+ under gst_object_*. ControlSources are now attached via GstControlBinding
+ to properties. There are no GValue arguments used anymore when programming
+ control sources.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </sect1>
+</chapter>
</para>
<para>
The bin will also manage the elements contained in it. It will
- figure out how the data will flow in the bin and generate an
- optimal plan for that data flow. Plan generation is one of the
- most complicated procedures in &GStreamer;. You will learn more
- about this process, called scheduling, in <xref
- linkend="section-threads-scheduling"/>.
+ perform state changes on the elements as well as collect and
+ forward bus messages.
</para>
<figure float="1" id="section-bin-img">
<itemizedlist>
<listitem>
<para>
- A pipeline: a generic container that allows scheduling of the
- containing elements. The toplevel bin has to be a pipeline,
- every application thus needs at least one of these. Pipelines will
- automatically run themselves in a background thread when started.
+ A pipeline: a generic container that manages the synchronization
+ and bus messages of the contained elements. The toplevel bin has
+ to be a pipeline, every application thus needs at least one of
+ these.
</para>
</listitem>
</itemizedlist>
</programlisting>
<para>
(This is a silly example of course, there already exists a much more
- powerful and versatile custom bin like this: the playbin2 element.)
+ powerful and versatile custom bin like this: the playbin element.)
</para>
<para>
- Custom bins can be created with a plugin or an XML description. You
+ Custom bins can be created with a plugin or from the application. You
will find more information about creating custom bin in the <ulink
type="http"
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html">Plugin
Writers Guide</ulink>.
</para>
<para>
- Examples of such custom bins are the playbin
2 and uridecodebin elements from<ulink
+ Examples of such custom bins are the playbin and uridecodebin elements from<ulink
type="http"
url="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-plugins/html/index.html">
gst-plugins-base</ulink>.
{
GstElement *pipeline;
GstBus *bus;
+ guint bus_watch_id;
/* init */
gst_init (&argc, &argv);
* GLib main loop is attached to below
*/
bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
- gst_bus_add_watch (bus, my_bus_callback, NULL);
+ bus_watch_id = gst_bus_add_watch (bus, my_bus_callback, NULL);
gst_object_unref (bus);
<!-- example-end bus.c a -->
[..]<!-- example-begin bus.c b -->
/* clean up */
gst_element_set_state (pipeline, GST_STATE_NULL);
gst_object_unref (pipeline);
+ g_source_remove (bus_watch_id);
g_main_loop_unref (loop);
return 0;
<itemizedlist>
<listitem>
<para>
- A pointer to a piece of memory.
- </para>
- </listitem>
- <listitem>
- <para>
- The size of the memory.
+ Pointers to memory objects. Memory objects encapsulate a region
+ in the memory.
</para>
</listitem>
<listitem>
The Glib Object system</ulink>.
</para>
<para>
- A <ulink type="http" url="&URLAPI;GstElementFactory.html">
+ A <ulink type="http" url="&URLAPI;GstElement.html">
<classname>GstElement</classname></ulink> also provides various
<classname>GObject</classname> signals that can be used as a flexible
callback mechanism. Here, too, you can use <command>gst-inspect</command>
<title>More about element factories</title>
<para>
In the previous section, we briefly introduced the <ulink type="http"
- url="&URLAPI;GstElement.html"><classname>GstElementFactory</classname></ulink>
+ url="&URLAPI;GstElementFactory.html"><classname>GstElementFactory</classname></ulink>
object already as a way to create instances of an element. Element
factories, however, are much more than just that. Element factories
are the basic types retrieved from the &GStreamer; registry, they
describe all plugins and elements that &GStreamer; can create. This
means that element factories are useful for automated element
instancing, such as what autopluggers do, and for creating lists
- of available elements, such as what pipeline editing applications
- (e.g. <ulink type="http"
- url="http://gstreamer.freedesktop.org/modules/gst-editor.html">&GStreamer;
- Editor</ulink>) do.
+ of available elements.
</para>
<sect2 id="section-elements-factories-details">
</para>
<para>
The last thing left to do is to add all elements into a container
- element, a <classname>GstPipeline</classname>, and iterate this
- pipeline until we've played the whole song. We've previously
+ element, a <classname>GstPipeline</classname>, and wait until
+ we've played the whole song. We've previously
learned how to add elements to a container bin in <xref
linkend="chapter-bins"/>, and we've learned about element states
in <xref linkend="section-elements-states"/>. We will also attach
GstElement *pipeline, *source, *demuxer, *decoder, *conv, *sink;
GstBus *bus;
+ guint bus_watch_id;
/* Initialisation */
gst_init (&argc, &argv);
/* we add a message handler */
bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
- gst_bus_add_watch (bus, bus_call, loop);
+ bus_watch_id = gst_bus_add_watch (bus, bus_call, loop);
gst_object_unref (bus);
/* we add all elements into the pipeline */
g_print ("Deleting pipeline\n");
gst_object_unref (GST_OBJECT (pipeline));
+ g_source_remove (bus_watch_id);
+ g_main_loop_unref (loop);
return 0;
}
</itemizedlist>
<para>
For convenience, it is possible to test <quote>playbin</quote> on
- the commandline, using the command <quote>gst-launch-0.10 playbin
+ the commandline, using the command <quote>gst-launch-1.0 playbin
uri=file:///path/to/file</quote>.
</para>
- <para>
- New applications should use playbin2 instead of the old playbin.
- </para>
</sect1>
<sect1 id="section-components-decodebin">
input from a source that is linked to its sinkpad and will try to
detect the media type contained in the stream, and set up decoder
routines for each of those. It will automatically select decoders.
- For each decoded stream, it will emit the <quote>new-decoded-pad</quote>
+ For each decoded stream, it will emit the <quote>pad-added</quote>
signal, to let the client know about the newly found decoded stream.
For unknown streams (which might be the whole stream), it will emit
the <quote>unknown-type</quote> signal. The application is then
static void
cb_newpad (GstElement *decodebin,
GstPad *pad,
- gboolean last,
gpointer data)
{
GstCaps *caps;
src = gst_element_factory_make ("filesrc", "source");
g_object_set (G_OBJECT (src), "location", argv[1], NULL);
dec = gst_element_factory_make ("decodebin", "decoder");
- g_signal_connect (dec, "new-decoded-pad", G_CALLBACK (cb_newpad), NULL);
+ g_signal_connect (dec, "pad-added", G_CALLBACK (cb_newpad), NULL);
gst_bin_add_many (GST_BIN (pipeline), src, dec, NULL);
gst_element_link (src, dec);
</itemizedlist>
<para>
Decodebin can be easily tested on the commandline, e.g. by using the
- command <command>gst-launch-0.10 filesrc location=file.ogg ! decodebin
+ command <command>gst-launch-1.0 filesrc location=file.ogg ! decodebin
! audioconvert ! audioresample ! autoaudiosink</command>.
</para>
<para>
- New applications should use decodebin2 instead of the old decodebin.
- </para>
- <para>
- The uridecodebin element is very similar to decodebin2, only that it
+ The uridecodebin element is very similar to decodebin, only that it
automatically plugs a source plugin based on the protocol of the URI
given.
</para>
through one or more <emphasis>sink pads</emphasis>. Source and sink
elements have only source and sink pads, respectively. Data usually
means buffers (described by the <ulink type="http"
- url="&URLAPI;gstreamer-GstBuffer.html"><classname>GstBuffer
- </classname></ulink> object) and events (described by the <ulink
- type="http" url="&URLAPI;gstreamer-GstEvent.html"><classname>
- GstEvent</classname></ulink> object).
+ url="&URLAPI;gstreamer-GstBuffer.html">
+ <classname>GstBuffer</classname></ulink> object) and events (described
+ by the <ulink type="http" url="&URLAPI;gstreamer-GstEvent.html">
+ <classname>GstEvent</classname></ulink> object).
</para>
</sect1>
<para>
A <emphasis>bin</emphasis> is a container for a collection of elements.
- A <emphasis>pipeline</emphasis> is a special subtype of a bin that allows execution of all
- of its contained child elements. Since bins are subclasses of elements
+ Since bins are subclasses of elements
themselves, you can mostly control a bin as if it were an element,
thereby abstracting away a lot of complexity for your application. You
can, for example change state on all elements in a bin by changing the
contained children (such as error messages, tag messages or EOS messages).
</para>
<para>
- A <emphasis>pipeline</emphasis> is a top-level bin. As you set it to PAUSED or PLAYING state,
- data flow will start and media processing will take place. Once started,
- pipelines will run in a separate thread until you stop them or the end
+ A <emphasis>pipeline</emphasis> is a top-level bin. It provides a bus for
+ the application and manages the synchronization for its children.
+ As you set it to PAUSED or PLAYING state, data flow will start and media
+ processing will take place. Once started, pipelines will run in a
+ separate thread until you stop them or the end
of the data stream is reached.
</para>
<!ENTITY DATAACCESS SYSTEM "advanced-dataaccess.xml">
<!-- Part 4: Higher-level interfaces -->
-<!ENTITY XML SYSTEM "highlevel-xml.xml">
<!ENTITY COMPONENTS SYSTEM "highlevel-components.xml">
<!-- Appendices -->
much control (and as much code), but will prefer to use a standard
playback interface that does most of the difficult internals for
them. In this chapter, we will introduce you into the concept of
- autopluggers, playback managing elements, XML-based pipelines and
- other such things. Those higher-level interfaces are intended to
+ autopluggers, playback managing elements and other such things.
+ Those higher-level interfaces are intended to
simplify &GStreamer;-based application programming. They do, however,
also reduce the flexibility. It is up to the application developer
to choose which interface he will want to use.
</partintro>
&COMPONENTS;
- &XML;
</part>
</para>
<para>
In addition, we also provide a porting guide which will explain
- easily how to port &GStreamer;-0.8 applications to &GStreamer;-0.10.
+ easily how to port &GStreamer;-0.10 applications to &GStreamer;-1.0.
</para>
</partintro>
The GST_MINI_OBJECT_READONLY flag was removed as it used to mark the
memory in buffers as READONLY. Marking memory READONLY can now be done
- with the GstMemory API. Writability of miniobjects is now only done by using
- the refcount.
+ with the GstMemory API. Writability of miniobjects is now either done
+ by using the refcount or by using exclusive locking.
* GstBuffer
A GstBuffer is now a simple boxed type this means that subclassing is not
init \
query \
typefind \
+ probe \
fakesrc \
playbin \
decodebin
init.c \
query.c \
typefind.c dynamic.c \
+ probe.c \
fakesrc.c \
playbin.c decodebin.c
typefind.c dynamic.c: $(top_srcdir)/docs/manual/advanced-autoplugging.xml
$(PERL_PATH) $(srcdir)/extract.pl $@ $<
+probe.c: $(top_srcdir)/docs/manual/advanced-dataaccess.xml
+ $(PERL_PATH) $(srcdir)/extract.pl $@ $<
+
fakesrc.c: $(top_srcdir)/docs/manual/advanced-dataaccess.xml
$(PERL_PATH) $(srcdir)/extract.pl $@ $<
projects / platform / upstream / gstreamer.git / commitdiff