Table of Contents
GStreamer is inherently multi-threaded, and is fully thread-safe. Most threading internals are hidden from the application, which should make application development easier. However, in some cases, applications may want to have influence on some parts of those. GStreamer allows applications to force the use of multiple threads over some parts of a pipeline. See the section called “When would you want to force a thread?”.
GStreamer can also notify you when threads are created so that you can configure things such as the thread priority or the threadpool to use. See the section called “Configuring Threads in GStreamer”.
Each element in the GStreamer pipeline decides how it is going to be scheduled. Elements can choose if their pads are to be scheduled push-based or pull-based. An element can, for example, choose to start a thread to start pulling from the sink pad or/and start pushing on the source pad. An element can also choose to use the upstream or downstream thread for its data processing in push and pull mode respectively. GStreamer does not pose any restrictions on how the element chooses to be scheduled. See the Plugin Writer Guide for more details.
What will happen in any case is that some elements will start a thread
for their data processing, called the “streaming threads”.
The streaming threads, or
GstTask objects, are
created from a
GstTaskPool when the element
needs to make a streaming thread. In the next section we see how we
can receive notifications of the tasks and pools.