]> &TITLEPAGE; Introduction GStreamer is a framework for creating streaming media applications. It is extremely powerful and versatile, and this versatility stems in part from its modularity, and its ability to incorporate new modules seamlessly into its framework. This document describes how to extend the capabilities of GStreamer by creating new plugins. It first describes the concepts required and the ways in which GStreamer can be extended. It then goes through a worked example of how to write a simple filter (for data processing), and how to test and debug it. More advanced concepts are then introduced, with worked examples of each. Next, writing source and sink elements (for performing input and output) is discussed. Finally, checklists of things to be sure to do when extending GStreamer are presented. &INTRO; Basic concepts This section introduces the basic concepts required to understand the issues involved in extending GStreamer &CONCEPTS; Building our first plugin We are now have the neccessary concepts to build our first plugin. We are going to build an element which has a single input pad and a single output pad, and simply passes anything it reads on the input pad through and out on the output pad. We will also see where we could add code to convert this plugin into something more useful. The example code used in this section can be found in examples/plugins/ &FIRSTPLUGIN; Building a simple test application &TESTAPP; Initialization Instantiating the plugins (NOTE: we really should have a debugging Sink) Connecting them Running the pipeline Loop-based Elements &LOOPBASED; How scheduling works, aka pushing and pulling How a loopfunc works, aka pulling and pushing Adding a second output Identity is now a tee Modifying the test application Types and Properties &TYPESNPROPS; Building a simple format for testing A simple MIME type Type properties Typefind functions and autoplugging Buffers and Metadata &BUFFERS; Anatomy of a Buffer Refcounts and mutability Metadata How Properties work efficiently Metadata mutability (FIXME: this is an unsolved problem) Sources and Sinks &SRCNSINK; Writing a source Pull vs loop based Region pulling (NOTE: somewhere explain how filters use this) Writing a sink Gee, that was easy State management &STATEMANAGE; What are states? Mangaging filter state Checklist &CHECKLIST; Things to check when writing a filter Things to check when writing a source or sink ===== Omega: a chain-based element has chain functions on each sink pad, the connected source pad may directly call (i.e. on the stack) the chain function Omega: each chain function is responsible for doing something useful, generally processing the buffer and pushing out the other end Omega: a loop-based element has a single function attatched to the element (not tha pads) that spins in a loop calling gst_pad_pull(sinkpad), do stuff, gst_pad_push(srcpad)