Michael Dominic posted a blog entry on the state of Diva. One of the major announcements he did was that he was looking into moving from GStreamer to MLT.
I usually try avoiding commenting on such decisions and instead let time decide wether they are wise or not, as making a comment on such things easily just cause bad feelings. Of course sometimes the need to make a comment overrides such concerns :)
One thing that Michael forgot to mention in his blog entry was that almost from the begining most of the GStreamer developers disagreed with the design choices he made in terms of Diva’s usage of GStreamer. Multiple times we tried to say that the Gnonlin approach was what we recommended and would be working towards enabling for these kind of applications. Michael disagreed and instead tried various alternative routes, which is why I feel somewhat unhappy about his claims about GStreamer in his blog. The rapid progress of Jokosher I feel validates our claims about Gnonlin to a large degree and I hope with our renewed effort into Pitivi we will have a 100% comparable application to Diva to prove our point with.
Edward added a reply to Michael’s blog pointing out some of the issues involved here, but one thing I want to expand upon and that is the issue of framework readiness. It is impossible to develop a framework such as GStreamer in isolation as there are always usecases and trouble areas that get lost or design decisions who seem clever from the framework point of view but which is a complete fuck up from the application developers point of view. This is a big part of the reason why GStreamer have taken so long to get to where it is today. Every time a new application type started using the framework we discovered that there where basic assumptions made in the core which simply didn’t hold true. This do make life for application developers a bit frustrating as they can get sucked into long periods of having to work on the framework and fixing bugs there instead of moving their application forward. I think people such as Stefan Kost with his Buzztard project and Edward Hervey with his Pitivi project can testify to that. The same is probably even true for the Totem and Rhythmbox projects who where among the early adopters of GStreamer. But thanks to the dedication and continous feedback of our application development community we have managed to ramp up the framework and also managed to keep the design pretty sane through it all.
I think this process is true for any major software project and I think no matter what multimedia framework Diva ends up using it will run into problems and deficiencies in the framework. The only framework which is sure to provide an application with all the features you could want working perfectly ‘today’ is one which already have applications using them sporting all the features you want. Which is why most music player developers for instance are pretty happy with GStreamer today, as there already are fully working high featured music players using the framework.
So on the GStreamer side applications such as Pitivi, Jokosher and Buzztard and Flumotion will continue to push the framework forward and resolve bugs and missing features as we find them. And while all the work going into for instance enabling DVD’s under GStreamer might feel like a unwanted distraction for a video editor developer I am pretty sure the long term effect of being able to easily import video from DVD’s directly into the editor will be a highly welcomed feature by the users.
I wish Michael good luck with Diva and trying out MLT, but I am pretty sure he will find that life there is just as painful, just with different set of bugs and missing features.