gstreamer/docs/pwg/other-oneton.xml
Ronald S. Bultje 835e826907 docs/pwg/: Document base classes, update sections of n-to-1 and 1-to-n (muxer, fix some code examples and links and u...
Original commit message from CVS:
* docs/pwg/advanced-clock.xml:
* docs/pwg/appendix-porting.xml:
* docs/pwg/intro-preface.xml:
* docs/pwg/other-base.xml:
* docs/pwg/other-manager.xml:
* docs/pwg/other-nton.xml:
* docs/pwg/other-ntoone.xml:
* docs/pwg/other-oneton.xml:
* docs/pwg/pwg.xml:
Document base classes, update sections of n-to-1 and 1-to-n (muxer,
demuxer), remove n-to-n (was never written), fix some code examples
and links and update the porting section to include all this.
2005-07-20 08:29:06 +00:00

45 lines
1.9 KiB
XML

<chapter id="chapter-other-oneton" xreflabel="Writing a Demuxer or Parser">
<title>Writing a Demuxer or Parser</title>
<para>
Demuxers are the 1-to-N elements that need very special care.
They are responsible for timestamping raw, unparsed data into
elementary video or audio streams, and there are many things that you
can optimize or do wrong. Here, several culprits will be mentioned
and common solutions will be offered. Parsers are demuxers with only
one source pad. Also, they only cut the stream into buffers, they
don't touch the data otherwise.
</para>
<para>
As mentioned previously in <xref linkend="chapter-negotiation"/>,
demuxers should use fixed caps, since their data type will not change.
</para>
<para>
As discussed in <xref linkend="chapter-scheduling"/>, demuxer elements
can be written in multiple ways:
</para>
<itemizedlist>
<listitem>
<para>
They can be the driving force of the pipeline, by running their own
task. This works particularly well for elements that need random
access, for example an AVI demuxer.
</para>
</listitem>
<listitem>
<para>
They can also run in push-based mode, which means that an upstream
element drives the pipeline. This works particularly well for streams
that may come from network, such as Ogg.
</para>
</listitem>
</itemizedlist>
<para>
In addition, audio parsers with one output can, in theory, also be written
in random access mode. Although simple playback will mostly work if your
element only accepts one mode, it may be required to implement multiple
modes to work in combination with all sorts of applications, such as
editing. Also, performance may become better if you implement multiple
modes. See <xref linkend="chapter-scheduling"/> to see how an element
can accept multiple scheduling modes.
</para>
</chapter>