gstreamer threading internal

[Tim-Philipp Müller]

On Tue, 2012-02-28 at 10:52 -0800, mirtexxan wrote:

> So If I understand correctly, in this case we'd have a totale of three
> threads: the application thread, the streaming thread (where elements live)
> and the "scheduling" thread that "moves" data and call chain, loop functions
> and the like?

Two threads. The "streaming threads" are "the scheduling threads" (I
don't think we use that terminology anywhere, do we?). Streaming threads
are the threads where the data processing happens, and data gets pushed
around. 

> Is there a situation when (apart from using queue) the gstreamer
> infrastracture generates more than this number of threads?
> *Note that I'm ignoring threads generated internally by the elements.*

Yes, there may be additional threads, e.g. a thread for the system
clock, or one for audio ring buffers, or an RTP jitterbuffer.


> It appears that I was wrong - I thought that each pad-to-pad connection in
> gstreamer lived in his own thread...

That is indeed not the case.

> so it appears that gstreamer DOES NOT SCALE AUTOMATICALLY to multicore
> machine with a high number of cores...

Well, no, and even if it did that, it's not clear that that would
automatically improve anything. In many cases, it will just add
unnecessary overhead. In practice, it's likely to take advantage of
multiple cores, if the kernel allows it to do so. Since you have audio
and video decoding typically in different streaming threads (remember
those queues after the demuxer), the kernel is likely to schedule audio
and video decoding to be done on multiple cores, for example.

Then it also depends on your codec implementations of course. Decoders
or encoders might automatically make use of multiple threads/cores
internally (without GStreamer necessarily knowing about it). e.g. x264,
libvp8, libav for decoding.


> ps a note on queue: what happens if I don't use queues after a demuxer?
> There will be only one thread in every case?

You need to use multiple queues because of the "preroll" mechanism in
GStreamer. Sinks will block when they receive a first buffer, and all
sinks need a buffer before the pipeline prerolls. That means you need
queues after demuxers and tees.

Cheers
 -Tim