summaryrefslogtreecommitdiff
path: root/manual-autoplugging.md
diff options
context:
space:
mode:
authorThibault Saunier <tsaunier@gnome.org>2016-06-17 18:41:07 -0400
committerThibault Saunier <tsaunier@gnome.org>2016-06-17 18:42:07 -0400
commit1c926934ab2873ddf909dfa0ae894c34666ea114 (patch)
treeaba4eaea37301e9fec7b88c6ccaaaa8992ea5bfd /manual-autoplugging.md
parent208c456f816bb2782cc5c47c5024e88479287c0c (diff)
Avoid having several 'h1' title per page
Each page has one title and it looks better like that
Diffstat (limited to 'manual-autoplugging.md')
-rw-r--r--manual-autoplugging.md6
1 files changed, 3 insertions, 3 deletions
diff --git a/manual-autoplugging.md b/manual-autoplugging.md
index f49c33c..60d65de 100644
--- a/manual-autoplugging.md
+++ b/manual-autoplugging.md
@@ -29,7 +29,7 @@ Lastly, we will explain how autoplugging and the GStreamer registry can
be used to setup a pipeline that will convert media from one mediatype
to another, for example for media decoding.
-# Media types as a way to identify streams
+## Media types as a way to identify streams
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
@@ -62,7 +62,7 @@ Now that we have an idea how GStreamer identifies known media streams,
we can look at methods GStreamer uses to setup pipelines for media
handling and for media type detection.
-# Media stream type detection
+## Media stream type detection
Usually, when loading a media stream, the type of the stream is not
known. This means that before we can choose a pipeline to decode the
@@ -181,7 +181,7 @@ Once a media type has been detected, you can plug an element (e.g. a
demuxer or decoder) to the source pad of the typefind element, and
decoding of the media stream will start right after.
-# Dynamically autoplugging a pipeline
+## Dynamically autoplugging a pipeline
See [Playback Components](manual-playback-components.md) for using the
high level object that you can use to dynamically construct pipelines.