GStreamer Developer Summit
From wednesday on, most GStreamer core developers and following (Andy, Benjamin, Christian, Dave, Julien, me, Thomas, Wim) got together to discuss future development and direction for the 0.9 branch . This will then become the final design for GStreamer 1.0; 1.0 would, in the end, be proposed for inclusion in both KDE and GNOME developer platforms. Big words, time for action.
Problems:
Current GStreamer-0.8 design has various generally agreed-on problems that cannot be fixed easily without breaking ABI/API. Worse, for a long time we did not know how to fix it and did not agree on a common direction towards fixing it.
- thread-safety issues (refcount-, signal-, state-change- related stuff and a lot more)
- clocking/synchronization issues
- state handling on eos/error is wrong
- negotiation protocol issues
- a lot more
Wim was leading the discussion to identify and agree on the mistakes in our current 0.8 tree, particularly the ones that we cannot fix in the 0.8 timeframe. This is mostly stuff that we agree on and know how to fix. It´s just something we need on paper for later.
Generally agreed-on solutions:
Here is what came out of this discussion:
- eos/error should not change state. More generally, state and actual processing (“scheduling”) should be separated from each other.
- refcounting should be threadsafe (glib)
- signals should be marshalled to the correct thread, either through a message bus or through cross-thread signal marshalling.
- Clocking should be improved to be implicitely synchronization (which we don´t have right now; *shame*) across streams.
Most of thursday was spent on discussing and agreeing on the above. We mostly agree on all this. Friday was spent talking about scheduling of pipelines (“processing of the media”).
Solution #1: -threaded:
-threaded is an experimental branch that aims to add locking in the right places, adds protocols on locking and variable usage and make it all just work. It also adds some nice extra features such as media processing on events (e.g. “preroll”, which means that the media is preloaded while a user executes an action).
Solution #2: -nonblock/async:
-async/noblock is another experimental branch that aims to remove the requirement for threads by using an event-based scheduling model. Elements are only scheduled when all preconditions for a non-blocking execution of their function is met (e.g. a file descriptor, a clock, etc.). Interesting features are seamless mainloop integration, which allows out-of-dataflow pipeline processing (e.g. expose an X window on expose events).
What’s next:
The rest of friday was spent on discussing both approaches, fetching problems, setting a short-term path and some more. Wim and Dave believe that the async/noblock approach can be merged in the otherwise nice -threaded approach (which already implements the other stuff that we agreed on).
Next few days, we’ll be experimenting with the design and implement all of the above. We will also discuss various directions for gst-plugins that are not directly related to GStreamer core. For the near future, we will work on preparing core to become the 0.9 branch, port the various subsystems from -threaded and -noblock/async over to this 0.9 branch (and have various people understand and review this), write a porting guide, remove deprecated code, write reference plugin implementations, updating documentation and porting plugins. From then on, we hopefully rock.
Time for beer. :).
