GStreamer Editing Services applies to the Season of Docs

The Pitivi video editor is based on the GStreamer Editing Services library. GES makes it easy to manage the timeline of a video project and export it to a new video file, and is carefully built to be reusable by other projects, not only Pitivi.

Since a few years ago, while not mentoring students for GSoC, we’ve been busy working on Pitivi 1.0. A large part of this was spent on fixing and improving the GES library. Time has come for the GES documentation to also be improved, to attract new users and contributors to the GStreamer ecosystem.

We’re applying to the Season of Docs program, where Google pays technical writers to contribute to open-source projects. Check out the technical writer guide for details and the program timeline, and read below if you are interested in working with us!

SeasonofDocs_Logo_SecondaryGreyProject ideas

As GES is a relatively small project, we have a single project idea, composed of multiple smaller tasks.

Write overviews and clarify the API reference

What GES is missing the most is a set of easy to understand high-level overviews for newcomers. You could write for example overviews about:

  • Assets and proxy management in a project
  • Timeline composed of Layers, and the output a/v tracks
  • Layers composed of various Clip types, and how these can be created
  • Effects which can be applied to Clips, and controllable properties

While preparing the high-level overviews you’ll dive into the API reference. The current API documentation is usable, but is not in the best shape. As you notice gaps, unclear sentences, missing details, you would either fix them on the spot or take note and fix them later. The entire API reference can then be reviewed and refreshed in this second step.

A stretch goal would be writing one or more tutorials, to exemplify easy video tasks which can be automated. The base code for these would be provided by us, and be most probably written in Python:

  • Cutting every third second of a video to produce a shorter video with skips,
  • Creating a photos slideshow with random transitions between the photos,
  • Displaying multiple videos at the same time in mosaics,
  • Animating a title clip in the center of the image from 0% to full size.

The GES overviews and tutorials would be kept in the GES git repository as markdown files. The API is documented in the source code written in C.

To get a better idea about the GES API, check the hierarchy of classes.

Work is going on right now to integrate the API documentation as HTML generated with Hotdoc into the GStreamer documentation, and should be ready by the end of the month.

If interested, get in touch with us as soon as possible, so we can prepare.


Dropping support for non-square pixels in Pitivi

Emerging from the long history of the video broadcast industry, there are legacy standards which specify rectangular pixels instead of square pixels. Yes, really! According to Wikipedia, non-square pixels originate in early digital TV standards:

The term pixel aspect ratio was first coined when ITU-R BT.601 (commonly known as “Rec. 601“) specified that standard-definition television pictures are made of lines of exactly 720 non-square pixels.

Today, we’re announcing that we will no longer support rendering non-square pixels. It will still be possible to use videos with non-square pixels in your projects, though.

Pitivi allowed creating projects with non-square pixels, but there were quality and behavior issues, such as this inconsistent viewer and renderer behavior related to them.

GStreamer Editing Services (GES), the library used by Pitivi for video processing, is very flexible and allows using videos of any video format in the same project. However, normally, in a “pro” setup, most video editing applications are very strict about the formats they accept as input, so Pitivi and GES were a bit unconventional with the “anything goes” approach.

This might give a clue as to why it was rather complicated and not very rewarding to “properly” fix the rectangular pixels problems in GES. The following question arose in our IRC channel (#pitivi on freenode):

[2017-10-30 14:37:38] <thiblahute> nekohayo: So my main question would be, do we really care these days to be able to produce non square output?

And we mostly came to the conclusion that only dinosaurs are producing content with rectangular pixels, and that with our limited resources we can’t afford to spend time and effort on this:

[2017-10-30 14:44:06] <nekohayo> so… it seems that non-square only matters for older formats

[2017-10-30 14:44:45] <nekohayo> and since we gave up on handling DV tapes/firewire anyway… we could as well declare PAR dead. Because f*** the 1990-2000’s

[2017-10-30 14:45:29] <nekohayo> Mathieu_Du’s only got love for you if you were born in the 80’s

[2017-10-30 14:46:58] <Mathieu_Du> the what again ?

[2017-10-30 16:36:38] <nekohayo> pixel aspect ratio (acceptable in the 80’s)

[2017-10-30 16:37:28] <Mathieu_Du> aha, knew that song from lubosz though 🙂

As a result of this simplification, the aspect ratio controls in the project settings dialog have been removed—one less thing for the user to worry about—and so the project width and height are now the only settings defining the display aspect ratio.

The aspect ratio settings removed from the project settings dialog

Migrating to GNOME’s GitLab

Three years ago we switched our bug tracker from Bugzilla to Freedesktop’s Phabricator instance. As very few projects were using it, the maintenance cost was too high for the gain, so the current plan is to obsolete it. Phabricator worked well for us, but now we say bye.

Luckily for us, GNOME hosts a GitLab instance since last year. We just migrated the Phabricator tasks to it and now we’re at

This was possible thanks to Thibault for extending the bztogl tool used to migrate the tasks, to Carlos for carefully running it, and to the GNOME community for everything.

We’ll certainly benefit a lot from the tighter integration with GNOME. This makes it much easier for GNOME contributors of all kinds to take part in our awesome video editor.

Pitivi 1.0 Release Candidate — “Ocean Big Chair”

We’re proud to release the first Pitivi 1.0 release candidate “Ocean Big Chair” (0.99). This release has many bug fixes and performance improvements, and is a release candidate for 1.0. Our test suite grew considerably, from 164 to 191 meaningful unit tests.

You can install it right away using Flatpak.


Early on this year, we got caught up in the Google Summer of Code. A lot of students hacked on Pitivi this spring, to get to know Pitivi better. As a result quite a few important fixes and improvements have been made. A big thank you to all of the students who contributed!

This summer we had three GSoC Pitivi projects. The GSoC work has been merged on the “master” branch and we made a separate “1.0” branch where we implement or backport the relevant fixes. A special thank you to Suhas Nayak and Ștefan-Adrian Popa, two of our GSoC students who contributed a large number of bugfixes and made possible this release.


As you might know, we’re focused on bug fixing until Pitivi 1.0. See what’s left to do for 1.0 in Phabricator.

We need people to test Pitivi (the Flatpak “stable” branch) and report back any crash or stability issue they notice, so we fix it. — If you want to help in any way, come to our IRC channel.

Three GSoC students hack on Pitivi this summer

We’re excited to have three students that will contribute to Pitivi this summer. Congratulations, Fabián Orccón, Suhas Nayak and Ștefan-Adrian Popa!

  • Fabián already had an internship with us two years ago. He’ll focus on a plugin system with great documentation for video hackers, and a first plugin for inspecting the timeline of the currently opened project in a Python console (T3193).
  • Suhas will focus on a modern color correction UI for the corresponding GStreamer plugin, and lay the path for similar changes to other effects (T2372).
  • Ștefan will focus on allowing users to apply Ken-Burns effects by manipulating the placement and zoom of the clips on the viewer (T7340).

You can follow the linked blogs or subscribe to the Phabricator tasks to stay up-to-date with the progress, or keep an eye on the Pitivi planet. Feel free to make suggestions about these projects on the corresponding tasks, or chat with us about them in our IRC channel. The official start of the coding period is May 30.

Besides mentoring for GSoC, the Pitivi maintainers are busy ironing out the last stability problems we’re aware of. We made great progress, expect version 0.99 sometime soon, followed by some more testing towards 1.0!

Thanks to Google for GSoC and to the GNOME Foundation for allowing us to have these projects under their umbrella this year!

Pitivi 0.98 — Getting there

This is another release focused on fixing bugs and improving stability.

Improved timeline

We switched our official build to use GTK 3.22 and the framework did not like how we were using it, spamming us with warnings in the console. We fixed those and improved the timeline in the process and added more unit tests.

It was quite a journey. Initially, the GTK Inspector was useful to figure out which widgets the widget IDs in the warnings identified. Then we had to go back between the GTK documentation and the #gtk+ IRC channel until we figured out we were changing the size of some containers in their do_draw methods, which was not good.

Accelerated development

Taking advantage of an opportunity, with the last money from our coffers (the remaining 2014 fundraiser donations and the GSoC mentor stipends) we hired Alexandru Băluț, a long-time Pitivi contributor, so he can focus better on fixing issues blocking the 1.0 release. Alex worked on Pitivi in Oct, Nov, and will allocate more time in Dec 2016. Thanks again to everybody who donated!

Customizable keyboard shortcuts

Jakub Brindza, our GSoC 2016 student, finished the customizable keyboard shortcuts feature. See how it works in the screencast below.

Supported muxers and encoders

In the previous version, 0.97, we picked a set of supported muxers, audio encoders, video encoders, added integration tests for them in GES, and changed the rendering dialog to show very clearly the ones which are unsupported.


See what’s left to do for 1.0 in the 0.99 and 1.0 columns in Phabricator. If you want to help in any way, come to our IRC channel. We prepared a nice list of tasks suitable for newcomers. These are good also for students interested to apply for a GSoC with us.

The build system has been ported to meson, no more autogen! 😉

Get Pitivi directly from us with Flatpak

Distributing apps as packages (deb, rpm, etc) is problematic. For example, the Pitivi package depends on the GTK package and Pitivi 0.95 broke in the distributions which updated to GTK version 3.20, because of the incorrect way we were using a virtual method. This is not the first time something like this happens. To avoid the slippery dependencies problem, two years ago we started making universal daily builds. They allowed everybody to run the latest Pitivi easily by downloading a large binary containing the app and all the dependencies.

A few problems still remained:

  • It was complicated to set up the Pitivi development environment. We had a huge script for setting up the development environment and new contributors always had problems. We tried to reuse the daily builds for preparing a development environment but it was hacky and we failed to make it work correctly.
  • Users were notified about available updates through a custom mechanism and updating was not ideal, requiring to download a huge binary blob.
  • Maintaining the AppImageKit based bundle required following many dependencies (security) updates and maintaining the build for them (even though we were sharing the burden with the whole GStreamer community, as we were using the Cerbero build system).

Recently Flatpak got our attention as it set out to fix these problems. Flatpak’s sandboxing allowed us to create a nice development environment. Our new dev env script reuses the one which flatpaks Pitivi so we got rid of the old ones. Also, Flatpak allows the user to only download binary diffs for updates. Moreover, the Gnome community already provides builds for their SDK and Runtimes, which contains almost everything we need for Pitivi; now, we only have to build a few libraries, which makes it much simpler for us to maintain the new bundles.

We’re enthusiastic about Flatpak. Jakub Steiner summarized Flatpak’s advantages very nicely:

Flatpak aims to solve the painful problem of the Linux distribution—the fact that the OS is intertwined with the applications. It is a pain to decouple the two to be able to:

  • Keep a particular version of an app around (and working, our note), regardless of OS updates. Or vice versa, be able to run an uptodate application on an older OS.
  • Allow application authors distribute binaries they built themselves. Binaries they can support and accept useful bug reports for. Binaries they can keep updated.

For now you need to use the command line to install Pitivi with Flatpak. In the near future, it should be trivial for you to install and manage our Flatpak build of Pitivi in your favorite software manager. GNOME Software is a good example.