#GstTask is used by #GstElement and #GstPad to provide the data passing
threads in a #GstPipeline.
A #GstPad will typically start a #GstTask to push or pull data to/from the
peer pads. Most source elements start a #GstTask to push data. In some cases
a demuxer element can start a #GstTask to pull data from a peer element. This
is typically done when the demuxer can perform random access on the upstream
peer element for improved performance.
Although convenience functions exist on #GstPad to start/pause/stop tasks, it
might sometimes be needed to create a #GstTask manually if it is not related to
a #GstPad.
Before the #GstTask can be run, it needs a #GRecMutex that can be set with
gst.task.Task.setLock.
A #GstTask will repeatedly call the #GstTaskFunction with the user data
that was provided when creating the task with gst.task.Task.new_. While calling
the function it will acquire the provided lock. The provided lock is released
when the task pauses or stops.
Stopping a task with gst.task.Task.stop will not immediately make sure the task is
not running anymore. Use gst.task.Task.join to make sure the task is completely
stopped and the thread is stopped.
After creating a #GstTask, use gst.object.ObjectGst.unref to free its resources. This can
only be done when the task is not running anymore.
Task functions can send a #GstMessage to send out-of-band data to the
application. The application can receive messages from the #GstBus in its
mainloop.
For debugging purposes, the task will configure its object name as the thread
name on Linux. Please note that the object name should be configured before the
task is started; changing the object name after the task has been started, has
no effect on the thread name.
#GstTask is used by #GstElement and #GstPad to provide the data passing threads in a #GstPipeline.
A #GstPad will typically start a #GstTask to push or pull data to/from the peer pads. Most source elements start a #GstTask to push data. In some cases a demuxer element can start a #GstTask to pull data from a peer element. This is typically done when the demuxer can perform random access on the upstream peer element for improved performance.
Although convenience functions exist on #GstPad to start/pause/stop tasks, it might sometimes be needed to create a #GstTask manually if it is not related to a #GstPad.
Before the #GstTask can be run, it needs a #GRecMutex that can be set with gst.task.Task.setLock.
The task can be started, paused and stopped with gst.task.Task.start, gst.task.Task.pause and gst.task.Task.stop respectively or with the gst.task.Task.setState function.
A #GstTask will repeatedly call the #GstTaskFunction with the user data that was provided when creating the task with gst.task.Task.new_. While calling the function it will acquire the provided lock. The provided lock is released when the task pauses or stops.
Stopping a task with gst.task.Task.stop will not immediately make sure the task is not running anymore. Use gst.task.Task.join to make sure the task is completely stopped and the thread is stopped.
After creating a #GstTask, use gst.object.ObjectGst.unref to free its resources. This can only be done when the task is not running anymore.
Task functions can send a #GstMessage to send out-of-band data to the application. The application can receive messages from the #GstBus in its mainloop.
For debugging purposes, the task will configure its object name as the thread name on Linux. Please note that the object name should be configured before the task is started; changing the object name after the task has been started, has no effect on the thread name.