mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-09-08 13:18:52 +00:00
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.
45 lines
1.9 KiB
XML
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>
|