[gst-devel] 0.9 proposals

[Wim Taymans]

On Mon, 2004-11-29 at 16:10 +0100, Benjamin Otte wrote:
> On Mon, 29 Nov 2004, Wim Taymans wrote:

Hi,

> 
> > first month:
> >  - write out specs for implementing push/pull return values.
> >  - patch core and plugins.
> >
> I want to get rid of push and pull. No element handles push and pull
> correctly (especially the fact that both push and pull may not return or
> that the element's state may have changed to NULL during the push or
> pull).

push and pull will always return with a return value, which can be
GST_FLOW_WRONG_STATE if the element performed a state change in the
get/chain function. Also pushing a buffer to a non negotiated pad will
return with an error code so that the plugin can shut down properly or
recover.

> 
> >  - agree on new negotiation, out of the state changes. Write specs.
> >  - agree on new thread safe state changes/scheduling model. Write
> >    specs. patch core plugins.
> >
> 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.

For efficient execution on SMP machines you need threads. For making
sure that the gui does not block the pipeline when doing updates you
need to be able to run parts in threads. Most apps currently use a
thread to run the pipeline (rb, playbin, totem, correct me if I'm wrong)
especially for this purpose. Getting rid of this sounds like a bad idea
unless you can guarantee that the GUI does not block for too long. 
The document outlines where locks should be placed. By minimizing the
interaction between objects one can make the locking fairly
straightforward, IMO. 

> 
> >  - write specs for GstBus. implement. patch plugins.
> >  - write testcases for all this.
> >
> What's GstBus? Something like IPC for gst?

It's a method for making the app communicate with messages (errors, EOS,
tags, ...) from the pipeline elements. It is able to deliver data to the
app through the mainloop so that it doesn't have to care about internal
streaming threads.

> 
> 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.
After writing and thinking about the document, the state changes,
preroll, message bus (with EOS) was written in 3 days. It's just the
start but I'm fairly confident it can be done. It also depends on how
many people are willing to implement their submodule.

> 
> > second month.
> >  - patch more plugins. with negotiation.
> >  - write specs and implement seeking in plugins.
> >  - write specs and implement clocking.
> >  - bugfix. try to port apps.
> >
> 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.
Do we have a good document listing the use cases? If not we'll have to
write one and figure out a way to handle the cases correctly. The
preroll phase proposal should make things a lot more easy.

> 
> > 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
No idea how it will work out this time...

Wim

> 
> Benjamin
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
-- 
Wim Taymans <wim at fluendo.com>