[gst-devel] 0.9 proposals

[Thomas Vander Stichele]

Hi,

> David and I agreed on the fact that we want to get rid of threads. Do not
> support threads in Gstreamer anymore, it only causes races. This of course
> only works with a non-blocking API. But if you want a threadsafe model
> you're in for quite a ride, especially with dynamic pipelines.

How do you make a non-blocking API out of a blocking API (say, a lib
you're wrapping in an element) without using threads ?
How would you write elements that are more performant or easier to write
using threads, like the v4lsrc elements or multifdsink ?
How do you make up for the performance loss of choosing a non-optimal
read/write/select model ?
How do you still achieve low-latency if you have to actively loop to
check for data processing ? How do you decide on the latency-vs-
performance tradeoff ?

> If you get a feature set like this done and running in a halfway decent
> way in a month, I'd be fairly impressed. Especially because it requires
> changes to plugins. The last change that required touching plugins (caps
> change) took at least 3 months to get right. I'd expect the same time
> here.

Are you saying that there's a good way to switch to a non-blocking model
and not have to touch all those plugins ?

> Seeking and clocking is another thing I'd expect 3 months for. And it's
> more than writing specs, we first need to find a way that works for all
> our use cases.

True.  So let's write down those use cases so there's something to talk
about.

> > third month.
> >  - stabelize, bugfix. release new core and plugins. docs fixes, etc...
> >
> stabilizing and bugfixing for this kind of stuff takes another three
> months. Or at least it took us that much time in 0.7 => 0.8

I think nobody disagrees that the 0.7 cycle was a disastrous mess.  It's
our hope we can do it a little more organized this time.  It would be
nice if we'd tackle problem by problem, and hover around a stable point
with testable features, even if it doesn't work completely at each step
of the way.  But it should be possible to have *some* measure of
stability and workingness throughout the development.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
If lovin' you is wrong
then I don't wanna be right
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/