[gst-devel] 0.9 proposals

Benjamin Otte in7y118 at public.uni-hamburg.de
Mon Nov 29 07:12:03 CET 2004


On Mon, 29 Nov 2004, Wim Taymans wrote:

> 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).

>  - 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.

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

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.

> 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.

> 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

Benjamin





More information about the gstreamer-devel mailing list