gstreamer/docs/manual/advanced-metadata.xml
Ronald S. Bultje 2abdd0bfda docs/manual/: Update (until threads/scheduling) Application Development Manual; remove GstThread, add GstBus, add sim...
Original commit message from CVS:
* docs/manual/advanced-clocks.xml:
* docs/manual/advanced-interfaces.xml:
* docs/manual/advanced-metadata.xml:
* docs/manual/advanced-position.xml:
* docs/manual/advanced-schedulers.xml:
* docs/manual/advanced-threads.xml:
* docs/manual/appendix-porting.xml:
* docs/manual/basics-bins.xml:
* docs/manual/basics-bus.xml:
* docs/manual/basics-elements.xml:
* docs/manual/basics-helloworld.xml:
* docs/manual/basics-pads.xml:
* docs/manual/highlevel-components.xml:
* docs/manual/manual.xml:
* docs/manual/thread.fig:
Update (until threads/scheduling) Application Development Manual;
remove GstThread, add GstBus, add simple porting checklist, add
documentation for tag writing, clocks, make all examples until this
part compile and run.
* examples/manual/Makefile.am:
Update from changes to Application Development Manual; add bus
example, remove thread example.
2005-06-29 09:25:51 +00:00

69 lines
3.1 KiB
XML

<chapter id="chapter-metadata">
<title>Metadata</title>
<para>
&GStreamer; makes a clear distinction between two types of metadata, and
has support for both types. The first is stream tags, which describe the
content of a stream in a non-technical way. Examples include the author
of a song, the title of that very same song or the album it is a part of.
The other type of metadata is stream-info, which is a somewhat technical
description of the properties of a stream. This can include video size,
audio samplerate, codecs used and so on. Tags are handled using the
&GStreamer; tagging system. Stream-info can be retrieved from a
<classname>GstPad</classname>.
</para>
<sect1 id="section-tags-read">
<title>Metadata reading</title>
<para>
Stream information can most easily be read by reading them from a
<classname>GstPad</classname>. This has already been discussed before
in <xref linkend="section-caps-metadata"/>. Therefore, we will skip
it here. Note that this requires access to all pads of which you
want stream information.
</para>
<para>
Tag reading is done through a bus in &GStreamer;, which has been
discussed previously in <xref linkend="chapter-bus"/>. You can
listen for <classname>GST_MESSAGE_TAG</classname> messages and handle
them as you wish.
</para>
<para>
Note, however, that the <classname>GST_MESSAGE_TAG</classname>
message may be fired multiple times in the pipeline. It is the
application's responsibility to put all those tags together and
display them to the user in a nice, coherent way. Usually, using
<function>gst_tag_list_merge ()</function> is a good enough way
of doing this; make sure to empty the cache when loading a new song,
or after every few minutes when listening to internet radio. Also,
make sure you use <classname>GST_TAG_MERGE_PREPEND</classname> as
merging mode, so that a new title (which came in later) has a
preference over the old one for display.
</para>
</sect1>
<sect1 id="section-tags-write">
<title>Tag writing</title>
<para>
Tag writing is done using the <classname>GstTagSetter</classname>
interface. All that's required is a tag-set-supporting element in
your pipeline. In order to see if any of the elements in your
pipeline supports tag writing, you can use the function
<function>gst_bin_iterate_all_by_interface (pipeline,
GST_TYPE_TAG_SETTER)</function>. On the resulting element, usually
an encoder or muxer, you can use <function>gst_tag_setter_merge
()</function> (with a taglist) or <function>gst_tag_setter_add
()</function> (with individual tags) to set tags on it.
</para>
<para>
A nice extra feature in &GStreamer; tag support is that tags are
preserved in pipelines. This means that if you transcode one file
containing tags into another media type, and that new media type
supports tags too, then the tags will be handled as part of the
data stream and be merged into the newly written media file, too.
</para>
</sect1>
</chapter>