GStreamer 0.10 |
2006-05-10
|
It's been out for almost half a year now. In that time we've done quite a few releases of all the modules, and things are improving at an incredible rate. It seems we're collecting more and more momentum along the way, and we're getting good feedback. We get a lot of bug reports, a fair fraction of which come with patches, which is excellent. And the GStreamer team is fixing those bugs at a good rate too, so our bug total is not growing out of control.
I've been told Bastien removed the 0.8 backend from totem today, which is excellent news. When you compare the 0.8 and 0.10 versions, the difference in stability and seeking is so big that you'd never want to use the 0.8 version again. The only big thing it's still lacking is DVD support. And all that really needs is a motivated hacker. Given how Seamless, a command-line DVD player with full support for menus and subtitles, works amazingly well with 0.10, there's no real technical obstacle to finish porting the last DVD elements to 0.10 and use them from Totem.
Development of Pitivi is more focused now, and it seems to be paying off, as it's now getting more usable on my system. Jono Bacon is working on Jokosher, the multi-track audio recorder. It's good to see new outside people coming in and reporting bugs.
Jono mentions in his post that he thinks he's finding bugs because this is the first time people are writing applications for non-playback cases. This is only partly true - adder has been around since 0.4, and for the use cases people used it, it has worked fine up until 0.10. With some of the core redesign, it broke for its primary use case - adding audio tracks on the fly to be mixed. Bad, surely - but probably a side effect of 0.10's focus on achieving perfect playback. Personally, I was so busy with other stuff (Flumotion among other things) that I never got back to porting the jukebox python example to 0.10, and never noticed adder had gone south this badly. In any case, people had been using adder without problems before 0.10, although Stefan was running into problems during 0.8 for his particular use case.
By now, Wim fixed adder, and it seems to be working well, so I should finish that port of the jukebox.
This week is the first time I'm writing some actual C elements for GStreamer 0.10 myself - it's been a while since I've last written one. I'm writing a payloader/depayloader for our Data Protocol, which is used in the TCP elements to be able to connect pipelines over the network. It can still be confusing to write elements, but it's great to be able to go through all the documentation and compare with the elements you know you can trust for correct implementations in core and base.
It's also a lot more fun to develop these driven by tests I write - writing the out-of-the-box behaviour I want first, and then implementing things in the element to make the tests pass. I've written most of the elements over the last few days while on holiday in Belgium, with lots of interruptions, and mostly when being on the train or a plane, so I forced myself to write the code bookend-style (meaning, writing the code from the outside in - writing start and end of a function, making sure I mirror allocations and deallocations correctly and things like that), putting in appropriate FIXME's every time I needed to hibernate so I could dump state for later.
While writing these elements I of course ran into some corner bugs again in GStreamer, or just some things that nobody is using because they obviously do not work :) But it's getting easier and easier to slice through the multi-level GStreamer cake.
At the moment I'm working on a bug I'm triggering in multifdsink for which I need to change the way it handles streamheaders. But I'm being a good boy, and first creating a unit test for multifdsink to codify the things it already does correct for streamheaders today, before changing it to take my case into account.
The fun thing about writing tests is that you always start with the easiest possible test case, and always think "writing this test is stupid, because there's no way this can go wrong, but let's flex our mental muscles first", and invariably something does actually go wrong somewhere. In this particular case, the simplest thing I did was creating the element, setting it to PLAYING, pushing a single buffer, then going back to NULL. The element was leaking the buffer passed in.
The good thing is that most problems we find are problems like these - small leaks that happen outside of the steady state and are easy to fix once identified. In that I think our unit tests and their valgrinding are helping immensely. Instead of acting on the belief that you're working on a decent project, you can have some practical verification that your project is improving steadily.
So all in all, I'm very happy with the direction GStreamer has taken for 0.10, and the way it has started oozing quality. We still have some ways to go, but there is a very solid foundation on which we're building now. Thanks to all the GStreamer hackers over the last six-seven years !