[gst-devel] queued pipeline
in7y118 at public.uni-hamburg.de
in7y118 at public.uni-hamburg.de
Thu Nov 13 08:18:17 CET 2003
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
More information about the gstreamer-devel
mailing list