[gst-devel] queued pipeline

[in7y118 at public.uni-hamburg.de]

Quoting Colin Walters <walters at verbum.org>:

> I don't like the idea of increasing the output latency.  People already
> complain that it takes too long.  
> 
I don't think you get an improvement from running another thread. I haven't 
really tested it so I don't know, but I think putting an mp3 decoder in a 
different thread is not what makes your app playback smoother.

I have really no clue though.

> For now it sounds like that is the case, but Benjamin was saying that
> fixing this was a post-0.8 goal.
> 
The queue element is broken, gst-launch { priority=2 fakesrc num-buffers=5 ! 
fakesink } deadlocks, SMP has random crashes, glsink can't assume to always be 
in the same thread which is important for the gl context, you can break caps 
nego everywhere by inserting threads and queues, even filesrc can be easily 
broken by mass sending events over thread boundaries, GstQueries block apps, 
we have tests in the testsuite that work or don't depending on the libc thread 
implementation, ... the list goes on.

(purely my opinion from now on)
This is all because threading does not work. Not at all. Everything that does 
work when you add a thread is by accident and because Linux threading on UP is 
so predictable.
Everybody using threads is totally on his own.
GStreamer needs a huge effort to make that possible. And feature freeze is Jan 
1.
:(


Benjamin