This section of the appendix will discuss shortly what changes to applications 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 Application Development Manual where needed. With this list, it should be possible to port simple applications to &GStreamer;-0.9 in less than a day. 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. Applications should no longer use signal handlers to be notified of errors, end-of-stream and other similar pipeline events. Instead, they should use the GstBus, which has been discussed in . The bus will take care that the messages will be delivered in the context of mainloop, which is almost certainly the application's main thread. The big advantage of this is that applications no longer need to be thread-aware; they don't need to use g_idle_add () in the signal handler and do the actual real work in the idle-callback. &GStreamer; now does all that internally. Related to this, gst_bin_iterate () has been removed. Pipelines will iterate in their own thread, and applications can simply run a GMainLoop (or call the mainloop of their UI toolkit, such as gtk_main ()). State changes can be delayed; ASYNC. In 0.8, events and queries had to manually be sent to sinks in pipelines (unless you were using playbin). This is no longer the case in 0.9. In 0.9, queries and events can be sent to toplevel pipelines, and the pipeline will do the dispatching internally for you. This means less bookkeeping in your application. For a short code example, see . Related, seeking is now threadsafe, and your video output will show the new video position's frame while seeking, providing a better user experience. The GstThread object has been removed. Applications can now simply put elements in a pipeline with optionally some queue elements in between for buffering, and &GStreamer; will take care of creating threads internally. It is still possible to have parts of a pipeline run in different threads than others, by using the queue element. See for details. Filtered caps -> caps-filter.