Threads

GStreamer has support for multithreading through the use of the GstThread object. This object is in fact a special GstBin that will start a new thread (using Glib's GThread system) when started.

To create a new thread, you can simply use gst_thread_new (). From then on, you can use it similar to how you would use a GstBin. You can add elements to it, change state and so on. The largest difference between a thread and other bins is that the thread does not require iteration. Once set to the GST_STATE_PLAYING state, it will iterate its contained children elements automatically.

Figure 1 shows how a thread can be visualised.

Figure 1. A thread

When would you want to use a thread?

There are several reasons to use threads. However, there's also some reasons to limit the use of threads as much as possible. We will go into the drawbacks of threading in GStreamer in the next section. Let's first list some situations where threads can be useful:

Figure 2. a two-threaded decoder with a queue

Above, we've mentioned the "queue" element several times now. A queue is a thread boundary element. It does so by using a classic provider/receiver model as learned in threading classes at universities all around the world. By doing this, it acts both as a means to make data throughput between threads threadsafe, and it can also act as a buffer. Queues have several GObject properties to be configured for specific uses. For example, you can set lower and upper tresholds for the element. If there's less data than the lower treshold (default: disabled), it will block output. If there's more data than the upper treshold, it will block input or (if configured to do so) drop data.