gstreamer threading internal

[Tim-Philipp Müller]

On Tue, 2012-02-28 at 08:14 -0800, mirtexxan wrote:

> Specifically there's an example that bugs me:
> 
>  +---------+    +----------+    +------------+    +----------+
>  | filesrc |    | identity |    | avidemuxer |    | fakesink |
>  |        src--sink       src--sink         src--sink        |
>  +---------+    +----------+    +------------+    +----------+
>          (l-g) (c-l)      (g)  (l)          ()   (c)
> 
>    * fakesink has a chain function and the peer pad has no
>      loop function, *no scheduling is done*.
>    * avidemuxer and identity expose an (g) - (l) connection,
>      a thread is created to call the sinkpad loop function.
>    * identity knows the srcpad is getrange based and *uses the
>      thread from avidemux to getrange data from filesrc*.
> 
> So here my two questions:
> 1) what exactly means that the fakesink-avidemuxer connection is not
> scheduled? Is a new thread generated or not?
> 2) In regards to the identity-filesrc connection, what exacly happens? is a
> new thread generated? If not, why? What are the general rules for thread
> generation?

A thread/GstTask is created for avidemux's sink pad which iterates
avidemux's loop function. avidemux pulls data from filesrc and pushes it
our towards fakesink. There's one streaming thread only, namely
avidemux's loop thread.

You basically have two main scenarios:

 (Source in pull mode) <-- pull <-- (demuxer/parser) --> push --> ...

 (Source in push mode) --> push --> ...

In the first case, the demuxer/parser are driving that particular
streaming thread, in the second case there's a thread operating for the
source, which just creates data and pushes it in a loop.

In addition to that, a queue element (required usually when branches
split, e.g. after demuxers or tee) will create a thread boundary, so
there'll be a new thread for every queue.

Some elements also have other internal threads, e.g. audio elements may
have a thread for the internal ring buffer.

 Cheers
  -Tim