[gst-devel] Problems with one threaded pipelines?

[Andy Wingo]

Hm, hit the wrong reply key!

-------- Forwarded Message --------
From: Andy Wingo <wingo at pobox.com>
To: ext-tommi.myohanen at nokia.com
Subject: Re: [gst-devel] Problems with one threaded pipelines?
Date: Sun, 29 Aug 2004 09:44:44 +0100
Hi Tommi,

On Mon, 2004-08-23 at 12:54 +0300, Tommi Myöhänen wrote:
> You mention in Plugin writer's guide that "opt scheduler can't really
> cope with multi-input/-output elements (with the elements linked to each
> of these in-/outputs running in the same thread) right now".
>  
> Can you be more specific what kinds of situations it can't handle? What
> kind of problems there might occur with multi-input/output elements?

The statement is true, but in a very restricted sense. The opt scheduler
works fine with multi-in / multi-out elements right now, provided that
the elements push and pull data at a constant rate. For example, in an
audio processing network, it might be that the buffer size is always the
same, and one buffer in on all pads will produce one buffer out on all
pads. In that case, there will be no problem.

The problem results from "data pens", where buffers live between when
gst_pad_push is called and the corresponding gst_pad_pull returns. One
has to be certain that there is no unnecessary buildup in these pens.
The scheduler tries its best by sorting the runqueue, putting terminal
sinks at the entry points of the pipeline. This results in data being
"sucked out" through the sinks, rather than "blown in" through the
sources. It's an analogy, but accurate I think: when you push into
somewhere, you put data into the pipeline, hoping that someone can deal
with it. But when you approach the pipeline from the perspective of
sucking data out of the end, you automatically have as few penned
buffers as possible.

Of course, there are pathological cases, where an element, by pushing
and pulling in a bizarre order, can cause an impossible situation. An
example would be the following pipeline with the hypothetical element,
"flaky":

fakesink ! tee tee0.src0!flaky0.sink0 tee0.src1!flaky0.sink1 flaky ! fakesink

Imagine that flaky0 pulls buffers from sink0 at twice the rate of sink1.
Every time it pulls on sink0, the scheduler will switch to tee0 to fill
the buffer pen, which will add one buffer to the pens of sink0 and
sink1. One can see that sink1 will accumulate extra buffers, and that
there's no way to fix the situation.

As far as I understand it, that's the limitation of opt. Otherwise, if
you're not making this kind of pipeline, it works quite well.

Regards,
-- 
Andy Wingo <wingo at pobox.com>
http://ambient.2y.net/wingo/