Pitivi 0.95 — Enfant Suisse7 min read

Hey everyone! It’s time for a new Pitivi release, 0.95. This one packs a lot of bugfixes and architectural work to further stabilize the GES backend. In this blog post, I’ll give you an overview of the new and interesting stuff this release brings, coming out from a year of hard work. It’s pretty epic and you’re in for a few surprises, so I suggest listening to this song while you’re reading this blog post.

Engine rework: completed.

Those of you who attended my talk at GUADEC 2013 might remember this particular slide:
kill gnonlin
Well, it’s done now. It’s dead and buried.
This is something I’ve had on my mind for so long, I was even having nightmares about it—literally. To give you an idea just how ancient gnonlin was from an architectural standpoint, it was created fourteen years ago, merely six months after the first release of GStreamer itself. Well, y’know, a lot of stuff happens in 13-14 years.
So, over the past year, Mathieu and Thibault gradually refactored GNonLin into NLE, the new non-linear engine inside GES. For details, see the previous two blog posts about our War Against Deadlocks: the story about the mixing elements and the story about the new engine using them (replacing gnonlin).
The resulting improvements in reliability are not only palpable in daily use, they are actually quantifiable with the results our GES gst-validate test suite runs:

  • In the 1.4 series: 154 tests pass out of 198 (22.2% failures)
  • With the 1.6 release: 198 tests pass out of 198
— "What's going on? Give me a sitrep!" — "The tests… they all pass!" — "What?!"
— “What’s going on? Give me a sitrep!”
— “The tests… they all pass!”
— “What?!”

Now 100% GTK, with new horizons

pitivi 0.95
We were hitting various limitations and bugs (such as this) in Clutter, the library we used to display and animate the project’s timeline. Eventually we came to a point where we had to change strategy and port the timeline to use pure GTK+ widgets, with Matplotlib for drawing the keyframes on clips. Quite some work went into the new timeline.
The viewer (the widget that shows the main video preview, above the timeline) using glimagesink was causing too many problems related to embedding in the X window. We switched to the new GtkSink instead, which also allowed us to test gtkglsink at the same time, as they are compatible.
Thanks to the new GTK timeline, we have a little surprise to show here: technically, Pitivi can also work on Mac OS X now. This is not an April Fool’s joke.

Some notes about the experiment are sitting there if you’re curious. At this time, we are not supporting the Mac OS version officially, because we don’t have the resources for that (yet?). I was told that we should be able to make something available for testing a Mac build once we reach 1.0. Want to make it happen sooner? Feel free to join us and to work on that.
Wait, that’s not all. These changes also allow us to make Pitivi work with the GDK Broadway backend, meaning we can even run Pitivi in a web browser! Yep, you heard that right. Pitivi in a web browser. What could possibly go wrong? 😉

Spit polishing

An improvement we’re quite happy about is that you can finally drag & drop a file from a different app directly to the timeline, to create a clip.
The layers’ representation changed somewhat. Previously, an audio-video clip would be displayed as two separate clips in the timeline, one for video and one for audio, on two separate layers. At times it was pretty awkward. While porting the timeline, Thibault simplified the layers model to have the notion of generic layers, in which audio-video clips are represented as a unified clip object. This also means that there is no more wasted space if the layer has only video or only audio.
Also worth mentioning:

  • We have resurrected the transformation box feature, but the UI is currently very primitive. See the Clip properties > Transformation section when a clip is selected on the timeline. You can also drag the image in the viewer to change the position of the selected clip at the current position and you can use the mouse wheel to zoom in/out.
  • While editing a project, every operation is saved in a scenario file. These can be used when reporting bugs. See how to use scenarios for reporting complicated bugs easily (or if you’re feeling geeky, the details about how the scenarios are used to automatically test the GES backend).
  • You can now copy/paste clips in the timeline.
  • We’re now compatible with smaller screen resolutions (such as 1024×768) again
  • We removed a bunch of widgets in the layer controls. They were placeholders for future features, we should put them back once the features actually become available.
  • Undo/redo has been disabled until we add unit tests and make sure it works properly. Until then you can Ctrl+S regularly.
  • See also the release notes for 0.95.

Infrastructure changes

  • The Pitivi team migrated from Bugzilla to Phabricator for bug/task tracking.
  • We now have a script to setup the development environment from the latest daily bundle. This hybrid approach makes it very easy for new developers to start hacking on Pitivi’s Python side without needing to build the rest.
  • It was difficult for us to keep using Dogtail, so we moved all the integration tests to GstValidate.
  • Some of you have suggested that we compress the all-in-one bundles using XZ, and so we did. Our packages are now 20% lighter than uncompressed tarballs, so they will take less time to download (which is nice if you’re using the dailies to test).
  • With some help from Jeffrey Schroeder, I have finally upgraded our MediaWiki instance to the latest stable release. We hadn’t upgraded it in four years (thankfully it was fairly locked down so we did not run into trouble), in big part because it was not version-controlled and thus was a pain in the butt to manage. I should be able to do a better job at keeping it up-to-date from now on.

Where do we stand on the fundraiser?

In terms of donations, less than the fundraiser’s first milestone was reached. Therefore, instead of working full-time and burning through the money in a matter of a few months, Thibault and Mathieu decided to work at a slower rate while simultaneously providing professional multimedia consulting services to put food on the table.
Nonetheless, they eventually reached the point where they had worked through all the donated funds, and so they continued in their free time. The GTK+ Timeline and GtkSink work, for example, is one of the big architectural changes that Thibault had to do on his spare time, without monetary compensation whatsoever.
Now is still a good time to let others know and ask those around you to donate! We appreciate it.

A call for ruthless testing

As it is much more stable already, we recommend all users to upgrade to Pitivi 0.95 and help us find remaining issues, if any. Until this release trickles down into distributions, you can download our all-in-one bundle and try out 0.95, right here and now. Enjoy!
You’re in luck: I already spent a lot of my (very limited) spare time testing and investigating the most serious issues. In fact, one of the reasons why it’s been so long since the last release is that I have been Thibault’s worse nightmare for months (there’s a reason why my name strikes fear in the hearts of GStreamer developers):
Every two weeks or so, Thibault would come to me and say, “Hey look, I fixed all your bugs, how about we release now?”. I would then spend a day testing and return with ten more bugs. Then he would fix them all, and I would find ten other bugs in different areas. Then he would fix them, and I would find another batch that I couldn’t test last time. And so on and so forth, from spring to autumn. For example, these are the bugs I’ve found just for the GTK Timeline. Can’t believe I haven’t killed that poor guy.
Now that the blocker issues are solved, I’m quite impressed with how much more reliable this version of Pitivi is shaping out to be now. But hey, we’re not perfect, maybe there are bugs we’ve overlooked, so please grab 0.95 and try to break it as hard as you can, reporting the issues you find (especially freezes, crashes, incorrect output, etc.). We want it to be solid. Go wild.
office space printer

Thank you for reading, commenting and sharing! This blog post is part of a série of articles tracking progress made with work related to the 2014 Pitivi fundraiser. Researching and writing quality articles takes a lot of time, so please be patient and enjoy the ride! 😉
  1. An update from the 2014 summer battlefront
  2. The 0.94 release
  3. The War Against Deadlocks, part 1: The story of our new thread-safe mixing elements reimplementation
  4. The War Against Deadlocks, part 2: GNonLin’s reincarnation
  5. The 0.95 release, the GTK+ timeline and sink
  6. Measuring quality/reliability through time (clarifying what gst-validate is)
  7. Our all-in-one binaries building infrastructure, and why it matters
  8. Samples, “scenario” files and you: how you can help us reproduce (almost) any bug very easily
  9. The 1.0 release and closure of the fundraiser



14 responses to “Pitivi 0.95 — Enfant Suisse”

  1. I can’t wait for the weekend to test it! What is the story behind the codename ? 🙂

    1. Mathieu Duponchelle Avatar
      Mathieu Duponchelle

      The basic assumption that swiss kids behave nicely.

    2. Thibault Saunier Avatar
      Thibault Saunier

      Inside joke, no wonder 🙂

  2. A bit of a fail posting news without offering bundles for the new version. But keep up the good work, hopefully less crashes now.

  3. Mathieu Avatar

    I can’t wait for it to land in Debian repos! Pitivi is by far my favorite video editing software, especially for its ease of use, but it was also veeeery frustrating for its seemingly random crashes or bugs.
    All in all: keep up the good work! Hope that we manage to revive the fundraising and reach the 1.0 milestone!
    (a quick note on that, but wouldn’t regular, more incremental releases make the project look more alive, and help for the fundraising?)

    1. Thibault Saunier Avatar
      Thibault Saunier

      It should already be online now, Sebastian already packaged it for debian 🙂

      1. Mathieu Avatar

        Probably needs some time to be available… Still limited to 0.94 (see https://packages.debian.org/search?keywords=pitivi). But that’s quite alright, I can wait a bit for the brand new Pitivi ! 🙂

  4.  Avatar

    Well, I just tried 0.95 and it crashed: first saying it couldn’t find a certain library and then saying it detected a severe problem and that only a restart could solve this problem. On a second try it worked with a different codec (VP9 instead of VP8) but the encoding process (I didn’t change any settings) would take 24 hours — and in the System Monitor it was using only 1 of 4 cores BTW.
    What would be better is if Pitivi could just export the cuts of a video to a file or something and which then could be used in a $ ffmpeg [-...] ./pitivi_export command.

    1. Please see the bug reporting instructions and file a bug report.

      On a second try it worked with a different codec (VP9 instead of VP8) but the encoding process (I didn’t change any settings) would take 24 hours

      That’s because libvpx’s VP9 encoder is very computationally expensive and still excruciatingly slow, not our fault.

      What would be better is if Pitivi could just export the cuts of a video to a file or something

      That’s mostly what a .xges project file is, then you could just use the “ges-launch” commandline tool to process it.

      1. drago01 Avatar

        Re vp9 encoding speed: https://groups.google.com/a/webmproject.org/forum/#!topic/codec-devel/0rjNpFerYs8 maybe you should retest with that.

      2.  Avatar

        When using the latest ffmpeg build I get the following encoding speeds when using all 4 cores and encoding a 1min test vid:

        • Using libx264: 15 FPS.
        • Using “[libvpx-vp9 @ …]”: 11 FPS.

        So, I don’t know where the 24h come from, but this is way too much/incorrect.
        Thanks, I’ll try the “ges-launch” tool out.

  5. Why don’t you use the GNOME wiki? And more generally using the gnome.org infrastructure, instead of adding sysadmin work just for Pitivi?
    Why not following an iterative development process? Every 6 months, have a stable and usable release. And slowly but surely doing big refactorings internally. Getting rid of old libraries could be done incrementally, by following the Strangler Application way:

    One of the natural wonders of this area are the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.

    So why do you think this wouldn’t work for Pitivi? Btw it’s the same for GIMP.

    1. Why don’t you use the GNOME wiki? And more generally using the gnome.org infrastructure, instead of adding sysadmin work just for Pitivi?

      Regarding the wiki, there are a couple of reasons:

      • Historical reasons: it’s been standalone for 11 years… from its inception, Pitivi was envisioned to not be a GNOME-exclusive app even though it adheres to many GNOME technologies and conventions.
      • We have so many pages (and “smart” categories) in there, it would be significantly more pain to migrate to anything else than to keep maintaining the wiki (which would be easy now that it’s not just a dumb tarball).
      • I hate MoinMoin wiki (from a user’s standpoint, it’s clunky as hell, especially compared to MediaWiki). Also, I am guaranteed that MediaWiki will still be around and well-maintained 10 years from now.

      So yeah, easier to just keep going with the current system, on that particular front. When it comes to the bug tracker, I’m personally a big fan of Bugzilla but others are not, hence the migration to a freedesktop infrastructure.

      Why not following an iterative development process? Every 6 months

      That’s what we tried doing. Big architecture work kept getting in the way. You don’t release half-broken stuff. Also, we need to get our fixes in GStreamer (which is not time-based) and have them released before us.