Comment on Diva

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.

8 thoughts on “Comment on Diva

  1. This may be a crazy idea, but from my perspective everyone has been raving about DIVA’s UI since it was first introduced via Michal’s blog. Why not just emulate the UI concepts he introduced, take them to their conclusion and release it as Pitivi? You guys could obviously nail the backend portion with GNonLin and Edward on board, and just mimic the UI work Michal has already done.

  2. I’m sorry for the negative tone below, I hope you’ll try to see through it and understand that (in &) at the end, the message I’m trying to convey is constructive.

    Pitivi still can not even do the simplest of many common editing tasks. Diva at least attempted to do some of them. How can Pitivi then validate the gnonlin design? You often speak of renewed efforts in various (very interesting) directions and things that are “almost” done. When will we finally see the results? It’s all promises so far.

    When will webcam chats work in farsight and gossip? When will DVD support _really_ be there? When will Realmedia RTP streams _really_ work in Totem? When will Pitivi be an editor of interest to users rather than prophets? Subtitles still hang Totem rather often. Those are things that matter. My final point: when will GStreamer _really_ matter based on its _merits alone_? It’s been a year, and there’s still little to no user-visible progress compared to earlier versions. Those are the things that make people use totem-xine.

    I’m not necessarily supporting Michal, and I agree with you that he’ll probably see as many – though different – bugs and shortcomings in MLT, don’t get me wrong. I’m just pricking through the PR and looking at features.

  3. Brad, well said. While PiTiVi might be working currently better than Diva, Diva has a FAR SUPERIOR UI to either Kino, PiTiVi, Open Movie Editor, AviDemux all the rest around there.

    So, personally, for me to use PiTiVi, I want the Diva UI. MDK might have cr*cked up on his engine choices, but he has created the best UI for a major app for Linux — ever.

    I would like PiTiVi to emulate it pixel by pixel too.

  4. Looking at GNonLin’s code I really can’t imagine how ONLY THAT could ever support all what Diva needs. I even had this funny idea that I was looking at the wrong repository.

    And I did read quite a lot of its code. Because it’s almost nothing. Which is fine. It’s in development. Unfinished. We understand!

    But your blog makes it look as if this GNonLin is soon going to be the holy grail framework of video editing. Then please finish it.

    Nor the changelog (frequency of changes) nor the current amount of support and features is anywhere near what a typical video editing session ‘for an amateur’ is going to require from this so-called ‘engine’.

    Just as how Ronald puts it: promises promises and promises. Lots of PR and few value.

    I can perfectly imagine that GNonLin doesn’t even come close to what MDK needs for his Diva project. Pitivi still can not even do the simplest of many common editing tasks.

    You didn’t convince me, Christian. You probably didn’t convince a lot software developers. Probably not a single software developer with a little bit of experience in video & multimedia editing. Like MDK. The problem, I guess, is that we DO take a look at the code and supported features and NOT only at your blog.

    The Eugenias of this world read your blog and go: oooh, cool engine. Waaaw. Nice story behind it! MDK cracked up on the Engine choice!! yeah yeah! But his UI is cooool! (insert more slashdot-style ranting here)

    Please add value, then make such people think that way. It’s not helping people like MDK on making the right choices.

    It’s helping them wanting to quit working on the project. Maybe MDK comes back from his adventure with a shitload of experience that he can put in your GNonLin thing? Maybe he’ll wrap it in a GSt-style API? Or do you prefer that he stops developing his project because now stupid comments from people (look at Eugenia’s comment) will make him think that he’s doing all this for a bunch of morons?

    Value. Then speak.

  5. I think that one problem with GStreamer is precisely that, being a work in progress, it’s been pushed too early as a finished product. For example, in mainstream distributions like Ubuntu and Fedora it’s been used for a long time now as Totem’s backend, and that has not been very wise IMHO. It has forced users to have to switch to Totem-xine as soon as they installed those distros in order to have a good multimedia experience. And it has made most people think that GStreamer is a bad product.

    Regarding DIVA and MDK, I’m not sure if he knew from the beginning that GStreamer was not ready for video editing but wanted to help it to become ready for it (like in Edward Hervey and Pitivi’s case), or if he just thought it was ready and then found out it isn’t. For how things have gone, I guess it’s the second case (and who knows if it’s been his own fault or if he thought so because the GStreamer people tried to “sell” it as a finished product).

    In any case, MLT might not be perfect, but it’s already working with different video editors. The recently released Kdenlive 0.4 is a good example of it (in fact, even in this early state, it’s the best Free/Open Source non-linear video editor I’ve seen so far).

    Good luck for Pitivi and Gstreamer anyway. I do believe that they are both going to be very important for Linux in the near future. Just let things go at it’s own rhythm and not try to make them go faster. People will be naturally adopting GStreamer as it becomes ready for each task. Until then, it’s good that apps out there use the best tool available (if there is a better tool available, that is).

  6. Phillip – I think you are being a bit harsh here. As someone who has delved deep into GStreamer to work on Jokosher, I am not going to suggest that GStreamer is perfect, but it has all the ingredients for perfection. I have never written a video editor with Gnonlin, but I have written an audio editor that involves non-destructive editing, and Gnonlin has proved to be an excellent solution.

    Sure, its not 100% finished yet, and that has been made clear, but I fail to see how using yet another multimedia backend is going to make things better. GStreamer is an extensible audio and video platform, and I am positive it is the right choice for Diva.

    It is important that PiTiVi and its lack of progress is not seen as a typical development use case for a GStreamer application. PiTiVi has had a rather painful history due to lack of developers and Edward concentrating on getting Gnonlin working. Not wanted to blow our own trumpet, but look at Jokosher – look what has been possible with GStreamer, Gnonlin and a fairly small development team.

    Phillip – I think it is unfair to accuse Christian as a hype-machine – he regularly reports on things that are going on in the GStreamer world, in the same way you talk about tinymail. Sure, some stuff is new, or broken, but the GStreamer developers have made huge strides in the last year ramping up the stability, something I have personally witnessed with my involvement in Jokosher.

    GStreamer is a good structural multimedia framework, and has a lot of potential. I would much rather see MDK help improve Gnonlin which would then have three major apps using it (Diva, Jokosher, PiTiVi). I can’t help but think that if MDK moves to a different framework, he will encounter as many problems. The grass always seems greener on the other side…


  7. Jono,

    Just like how Gnonlin isn’t ready for an application like Diva, is tinymail not ready for an application like Evolution.

    Which is why I very often mention that tinymail is for mobile devices and embedded appliances with a limited set of required functionality (but also a specific set, which is why I usually say that I have put a focus on these platforms).

    Having that focus is important, in my opinion.

    In my comment to this blog I wrote that we (or I) understand what “in development” means. Gnonlin is not yet ready for what Diva needs, which is fine. We thank you guys for wanting to do this library. It’s great that people work on things like this.


    It seems MDK decided that he wants a framework that is a little bit more mature than GStreamer + Gnonlin. If that is his decision then it’s not a design mistake if he picks another framework.

    It just means that he’s planning to focus on other things besides framework development. Maybe Diva’s user interface? I don’t know. MDK knows and MDK decides about this. The GStreamer people nor me nor you do.

    And I think he, being the Diva expert, made the right decision. So it was unnecessary to tell him that he made a wrong ‘design’ decision. IMHO.

  8. Philip, considering you don’t seem to have any clue about the development history of either gnonlin or Diva I find your comments a bit misplaced. Michal directed some hard criticism of GStreamer in his blog entry which I felt entitled to reply to, given the fact that instead of going with Gnonlin which we recommended from the begining he instead wrote his own editing engine on top of GStreamer using a different design/approach than Gnonlin. Unfortunatly I don’t remember the name of this engine anymore and it was never disitributed stand-alone.

    That was the design mistake I talked about. Also considering the tone you have been using in your blog entries about Evolution I feel this criticism from you a ‘bit’ out of place.

Comments are closed.