[gst-devel] autoplugging and 0.9

[Erik Walthinsen]

Ramón García wrote:
> Sorry, this message is difficult to read without
> context.
>  
> Wingo was against automatic placement of threads by
> the scheduler. I was supporting it.

I suppose I should weigh in on this issue, though I haven't seen the 
arguments either way.

Requiring threads to be placed explicitly by the application was the 
VERY FIRST design choice made, long before any code was even conceived, 
or even ANY other design issues were thought about.  This issue is the 
primary reason GStreamer ever existed in the first place.  Both the OGI 
Quasar player (which directly inspired GStreamer by both is features and 
misfeatures, mainly this issue) and DirectShow place every single 
element in its own thread, and thus queues between them.

The fundamental problem with doing this is that there is no control over 
how consistently any given thread is scheduled by the kernel, and 
therefore all queues have to be oversized.  Every element added to a 
pipeline (a DVD pipeline has ~6-8 elements between the disk and the 
user) adds another essentially uncontrolled queue, which because of 
various constants in the kernel (100Hz jiffies being a primary factor, 
the design of the scheduler being another), requires that queues be far 
more than one 33ms frame-time each.  With many elements, total queue 
length typically exceeds 1 second.

Applications that require low latency and low jitter (any live 
processing of audio, video, etc.) fundamentally cannot be implemented 
with a system that has implicit queues.  Strict control over latency is 
only possible with pipelines engineered from the ground up to use no 
queues, passing all data immediately from element to element.


However, the design of GStreamer's scheduler subsystem means that there 
is nothing keeping someone from creating a scheduler that does in fact 
implement implicit threads and queues between all elements.  As a matter 
of fact I think such a scheduler is long overdue, because it can be 
constructed in such a way as to "guarantee" proper execution of 
pipelines in ways that the normal scheduler has yet to achieve.  As such 
it can act as a reference scheduler, where certain performance 
characteristics like latency are irrelevant, but cannot be the default 
by any means whatsoever.