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. 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 gst_element_get_pad (), gst_pad_get_name () 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. In 0.8, scheduling could happen in any way. Source elements could be _get ()-based or _loop ()-based, and any other element could be _chain ()-based or _loop ()-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 . As a result of this, the bytestream object no longer exists. Elements requiring byte-level access should now use random access on their sinkpads. 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 . base classes, async state changes.