I gave my talk titled “Towards GStreamer 1.0” at the Gran Canaria Desktop Summit on Sunday. The slides are available here
My intention with the talk was to present some of the history and development of the GStreamer project as a means to look at where we might go next. I talked briefly about the origins of the project, its growth, and some of my personal highlights from the work we’ve done in the last year. To prepare the talk, I extracted some simple statistics from our commit history. In those, it’s easy to see both the general growth of the project, in terms of development energy/speed, as well as the increase in the number of contributors. It’s also possible to see the large hike in productivity that switching to Git in January has provided us.
The second part of the talk was discussing some of the pros and cons around considering whether to embark on a new major GStreamer release cycle leading up to a 1.0 release. We’ve successfully maintained the 0.10 GStreamer release series with backwards-compatible ABI and API (with some minor glitches) for 3.5 years now, and been very successful at adding features and improving the framework while doing so.
After 3.5 years of stable development, it’s clear to me that when we made GStreamer 0.10, it really ought to have been 1.0. Nevertheless, there are some parts of GStreamer 0.10 that we’re collectively not entirely happy with and would like to fix, but can’t without breaking backwards compatibility – so I think that even if we had made 0.10 at that point, I’d want to be doing 1.2 by now.
Some examples of things that are hard to do in 0.10:
- Replace ugly or hard to use API
- ABI mistakes such as structure members that should be private having been accidentally exposed in some release.
- Running out of padding members in public structures, preventing further expansion
- Deprecated API (and associated dead code paths) we’d like to remove
There are also some enhancements that fall into a more marginal category, in that they are technically possible to achieve in incremental steps during the 0.10 cycle, but are made more difficult by the need to preserve backwards compatibility. These include things like adding per-buffer metadata to buffers (for extensible timestamping/timecode information, pan & scan regions and others), variable strides in video buffers and creating/using more base classes for common element types.
In the cons category are considerations like the obvious migration pain that breaking ABI will cause our applications, and the opportunity cost of starting a new development cycle. The migration cost is mitigated somewhat by the ability to have parallel installations of GStreamer. GStreamer 0.10 applications will be able to coexist with GStreamer 1.0 applications.
The opportunity cost is a bit harder to ignore. When making the 0.9 development series, we found that the existing 0.8 branch became essentially unmaintained for 1.5 years, which is a phenomenon we’d all like to avoid with a new release series. I think that’s possible to achieve this time around, because I expect a much smaller scope of change between 0.10 and 1.0. Apart from the few exceptions above, GStreamer 0.10 has turned out really well, and has become a great framework being used in all sorts of exciting ways that doesn’t need large changes.
Weighing up the pros and cons, it’s my opinion that it’s worth making GStreamer 1.0. With that in mind, I made the following proposal at the end of my talk:
- We should create a shared Git playground and invite people to use it for experimental API/ABI branches
- Merge from the 0.10 master regularly into the playground regularly, and rebase/fix experimental branches
- Keep developing most things in 0.10, relying on the regular merges to get them into the playground
- After accumulating enough interesting features, pull the experimental branches together as a 0.11 branch and make some released
- Target GStreamer 1.0 to come out in time for GNOME 3.0 in March 2010
This approach wasn’t really possible the last time around when everything was stored in CVS – it’s having a fast revision control system with easy merging and branch management that will allow it.
On Thursday, we’re having a GStreamer summit in one of the rooms at the university. We’ll be discussing my proposal above, as well as talking about some of the problems people have with 0.10, and what they’d like to see in 1.0. If we can, I’d like to draw up a list of features and changes that define GStreamer 1.0 that we can start working towards.
Please come along if you’d like to help us push GStreamer forward to the next level. You’ll need to turn up at the university GCDS venue and then figure out on your own which room we’re in. We’ve been told there is one organised, but not where – so we’ll all be in the same boat.
The summit starts at 11am.
5 thoughts on “Towards GStreamer 1.0 talk”
Interesting read together with the slides, I’ve only been poking with GStreamer since the time between 0.8 and 0.10, so there’s a lot I had no idea about. I hope we’ll see an 1.0 eventually, 0.10 sure has been stable enough. At the top of my wish-list would be stride handling and maybe a base class for color space conversion so it could be done inside the video decoder without a buffer copy in between. Keep up the good work!
Please consider making hardware acceleration support a priority and making sure such support is easy to integrate.
Also to prevent security flaws in codecs reach out to the system a virtual machine / sandbox like Google’s Native Client might be worth to look into for a possible integration.
From reading the slides, I do agree with pretty much everything you said.
There’s two things I’d like to focus on: I don’t think 6 months is enough time to get the refactorings you want in, when you maintain a job and a stable branch at the same time. 1 year should be enough ok though, so let’s just hope GNOME is slow, too. 🙂
And the other thing is a thing I’ve been preaching to Edward about: GStreamer does not provide a clear path to getting proficient with it for new developers. How do people get from “I have no clue what GStreamer is and want to write an application” to “I just released gst-cubase 1.0”?
I think GStreamer loses a lot of people to ffmpeg/vlc/choose-your-poison along the road, because they feel overwhelmed by the complexities – from as early as when they can’t figure out they need an audioconvert in their gst-launch pipeline to deadlocks they get from plugging stuff that is too complex probably up to using gnonlin with incomplete muxers.
I had rather long rants about it – you should poke Edward about it, I hope he remembers most of it (I certainly ranted long enough ;)). Or ask me on IRC; it feels kinda awkward to put it into blog comments.
Interesting reading Jan, thanks!