mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-24 02:31:03 +00:00
aaf787f488
Original commit message from CVS: * docs/pwg/advanced-events.xml: * docs/pwg/advanced-request.xml: * docs/pwg/advanced-scheduling.xml: * docs/pwg/appendix-porting.xml: * docs/pwg/building-boiler.xml: * docs/pwg/intro-preface.xml: * docs/pwg/other-ntoone.xml: Rewrite scheduling-chapter for scheduling model in 0.9. Add lots of example code and explanation for pad activation, loop() and getrange() functions and a bit more. Remove old comments pointing to loop-functions. * examples/pwg/Makefile.am: Add loop/getrange examples.
62 lines
2.8 KiB
XML
62 lines
2.8 KiB
XML
<chapter id="chapter-porting">
|
|
<title>Porting 0.8 plug-ins to 0.9</title>
|
|
<para>
|
|
This section of the appendix will discuss shortly what changes to
|
|
plugins will be needed to quickly and conveniently port most
|
|
applications from &GStreamer;-0.8 to &GStreamer;-0.9, with references
|
|
to the relevant sections in this Plugin Writer's Guide where needed.
|
|
With this list, it should be possible to port most plugins to
|
|
&GStreamer;-0.9 in less than a day. Exceptions are elements that will
|
|
require a base class in 0.9 (sources, sinks), in which case it may take
|
|
a lot longer, depending on the coder's skills.
|
|
</para>
|
|
|
|
<sect1 id="section-porting-objects">
|
|
<title>List of changes</title>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Most functions returning an object or an object property have
|
|
been changed to return its own reference rather than a constant
|
|
reference of the one owned by the object itself. The reason for
|
|
this change is primarily threadsafety. This means, effectively,
|
|
that return values of functions such as
|
|
<function>gst_element_get_pad ()</function>,
|
|
<function>gst_pad_get_name ()</function> and many more like these
|
|
have to be free'ed or unreferenced after use. Check the API
|
|
references of each function to know for sure whether return
|
|
values should be free'ed or not.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
In 0.8, scheduling could happen in any way. Source elements could
|
|
be <function>_get ()</function>-based or <function>_loop
|
|
()</function>-based, and any other element could be <function>_chain
|
|
()</function>-based or <function>_loop ()</function>-based, with
|
|
no limitations. Scheduling in 0.9 is simpler for the scheduler,
|
|
and the element is expected to do some more work. Pads get
|
|
assigned a scheduling mode, based on which they can either
|
|
operate in random access-mode, in pipeline driving mode or in
|
|
push-mode. all this is documented in detail in <xref
|
|
linkend="chapter-scheduling"/>. As a result of this, the bytestream
|
|
object no longer exists. Elements requiring byte-level access should
|
|
now use random access on their sinkpads.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Negotiation is asynchronous. This means that negotiation is,
|
|
downstream, done as data comes in and, upstream, as renegotiation
|
|
is required. All details are described in <xref
|
|
linkend="chapter-negotiation"/>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
base classes, async state changes.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
</chapter>
|