Chapter 14. Threads

Table of Contents

Constraints placed on the pipeline by the GstThread
When would you want to use a thread?

GStreamer has support for multithreading through the use of the GstThread object. This object is in fact a special GstBin that will become a thread when started.

To construct a new thread you will perform something like:

  GstElement *my_thread;

  /* create the thread object */
  my_thread = gst_thread_new ("my_thread");
  /* you could have used gst_element_factory_make ("thread", "my_thread"); */
  g_return_if_fail (my_thread != NULL);

  /* add some plugins */
  gst_bin_add (GST_BIN (my_thread), GST_ELEMENT (funky_src));
  gst_bin_add (GST_BIN (my_thread), GST_ELEMENT (cool_effect));

  /* link the elements here... */
  ...
  
  /* start playing */
  gst_element_set_state (GST_ELEMENT (my_thread), GST_STATE_PLAYING);

    

The above program will create a thread with two elements in it. As soon as it is set to the PLAYING state, the thread will start to iterate itself. You never need to explicitly iterate a thread.

Constraints placed on the pipeline by the GstThread

Within the pipeline, everything is the same as in any other bin. The difference lies at the thread boundary, at the link between the thread and the outside world (containing bin). Since GStreamer is fundamentally buffer-oriented rather than byte-oriented, the natural solution to this problem is an element that can "buffer" the buffers between the threads, in a thread-safe fashion. This element is the queue, described more fully in Chapter 15, Queues. It doesn't matter if the queue is placed in the containing bin or in the thread itself, but it needs to be present on one side or the other to enable inter-thread communication.