Call for testing the Pitivi 1.0 RC

Pitivi 1.0 is scheduled to be released on Monday, May 20th. All the important bugs we were aware of have been fixed.

To fix one of the last issues, Thibault very recently rewrote the timeline/layers/clips management in GES, and this might have introduced new bugs. While we have lots of tests which all pass, they don’t cover everything.

We ask you to test the 1.0 RC! Grab a bunch of video files shot with your phone or camera and make some video out of them, trying various features. Tell us if you notice problems, and if you can reproduce them please file an issue describing the steps to reproduce the bug.

You can find us in the #pitivi IRC channel on FreeNode, or in this bridged Pitivi Matrix room.

How to install

To install the Pitivi 1.0 RC, simply run:

flatpak install

If there are conflicts, you can uninstall the conflicting installation.

How to test

Start Pitivi from the console, and keep it in view to notice any warnings or errors which might show up:

flatpak run org.pitivi.Pitivi//stable

You should be able to use any video file supported by GStreamer, but we officially support only a limited set of formats. If the file appears in the media library with a warning sign, right-click it and select proxy to create an optimized media file used automatically instead of the original.

Most useful would be to test the timeline editing, which should be responsive and precise. Try for example splitting and trimming clips, moving them around. Try ungrouping audio-video clips to make the respective video shorter than the audio. Overlap clips to create cross-fade transitions.

If time allows, you can also try adding effects, for example adding a background to a green screen. Mix diverse footage formats in the same timeline. Make a slideshow and include title clips and background music.

For reference, see the user manual. At the end, please render it and show us what you did!

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, about to be released. 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!

UPDATE: We’ve been accepted, see the list of accepted open-source organizations.

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.

The current GES documentation is integrated into the GStreamer documentation. The structure is specified in docs/sitemap.txt, and the HTML is generated with Hotdoc out of the C files and other markdown bits.

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.

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.