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.
Besides the usual cleanup and bug squashing, this release brings a fundamental feature which greatly improves the edit experience. Now you can edit and render a video project with any video files with great accuracy, thanks to proxy files.
Proxy editing: fast and accurate editing with any video format
The harsh reality of this world is that there is only a limited set of formats that really work well for video editing. Without those, rendering a project could have been inaccurate at times*. The user experience degrades when using container formats not designed for fast & accurate seeking. For example, seeking a video format where the keyframes are followed by one or more inter-frames (such as in VP8, H.264) is often slow.
To provide the best experience, we decided to give you the ability to seamlessly work with media formats suitable for video editing. This is accomplished with what we call “proxy” files. Other video editors advertise the use of downscaled proxy files which, besides the improved reliability, also provide better performance when the system is not powerful enough to handle high-quality video files in real-time. We do not cover the the downscaled proxy files case yet—that’s planned for post 1.0. For now, our proxies are high-quality proxies intended to be used instead of the original, when editing and also when rendering the project.
Oh, and since we’re so smart, we now also generate the audio waveforms and filmstrip thumbnails at the same time as we are processing proxies. Super efficient.
So what is the difference between an original and its “proxy”? The proxy is a slightly degraded but easier-to-work-with version of the original:
Okay, okay, we might be stretching the analogy a little bit, but you get the picture.
When are proxies needed for stability?
The whitelist below shows the formats we officially support—which can be used safely without proxying them. For the rest, we recommend using proxy files to guard against bugs in the decoders and demuxers. Depending on how popular other formats get, we will consider officially supporting them. The intention is to keep the list short to avoid spending too much time on decoders and demuxers.
At the moment, the whitelist is comprised of the following:
Containers: QuickTime, Ogg, Matroska, WebM
Video codecs: H.264, MJPEG, VP8, Theora, raw
Audio codecs: Opus, MP3, Vorbis, FLAC, raw
How does it work?
When you import an asset with an unsupported format, it is by default transcoded using a codec suitable for video editing. You can disable or force the proxy creation on a per-asset basis, when you import or later at any time. Finally, when rendering, you can specify whether to use the proxies or the original files. You are always in control.
As seen in the screenshots above, the state of an asset’s proxy is shown by an icon in the bottom-left corner of the asset thumbnail, in the Media Library. The icon can be one of:
none The original is used.
The proxy is being created by transcoding the asset.
The proxy is ready and is used automatically.
The proxy creation failed and the original is used.
The main disadvantage of using the intermediate proxy files for rendering is that some quality is lost when transcoding, but this is not noticeable in most cases. Other than that, transcoding the originals takes a bit of time and they take some disk space (around 10 times more for H.264 content, for example). In practice, we think that using proxy files is the best option. You decide what works for you but take into account what is considered safe and officially supported, and what is not.
It was very important to pick a codec that preserves the visual quality of the originals, so that final renders can be done out of the intermediate proxy files with no perceived quality loss. The other requirement was that seeking should be fast, meaning it had to be an intra-frames-only codec, where a frame is encoded and decoded independently of any other frame. Currently Pitivi uses MJPEG or ProRes for the proxy files, depending on which is available on the system.
For now, the audio is transcoded using Opus, even though it’s a lossy format, because the codec is very good. We’ll most probably switch to FLAC when it will be more supported in GStreamer because it loses no quality and has a pretty good compression ratio.
Scrubbing the timeline easily
Currently the user is able to select, move and edit clips by using the left mouse button. This is exactly how a user expects to interact with a GTK UI and it works very well. In addition to that, when clicking using the left mouse button, a seek is performed and the playhead is moved to that position. Some users were annoyed by this combined behavior so we added an option for disabling seek on left-click, but this was not enough.
Inspired by Blender’s different functionality assignation for left and right mouse buttons, we added the ability to seek by right-clicking. Now you can quickly and safely scrub on the timeline as well on the ruler using the right mouse button. Since Pitivi did not provide a context menu when right-clicking on the timeline, it was easy to make this possible. Try it out and let us know what you think. More details on the reasoning that led to this are visible in T3158.
The transformation box is back, thanks to Collabora and Lubosz Sarnecki! This is the third implementation of the transformation box, first one being hacky and second one being available only for users with GL video cards. Now it works great due to the almighty GtkSink, GStreamer’s latest GTK widget for displaying video.
The new transformation box fits great with Pitivi by making clips selectable from the viewer, so you can manage multiple overlapping clips quite easily. But the best part of this implementation may be its extensibility, an example being the module for the title clips.
Project settings: letting the computer figure things out
At least one of our contributors felt intimidated when he first saw the project settings dialog which used to show up when creating a new project. The project settings define how you preview the project while editing. You might want for example to choose a small video size if your computer is not very powerful, then at render time change that to get the best quality. These settings can be changed safely at any time.
The question was whether showing that dialog is really necessary at that point in time. Well, not really. Now, when you create a new project, some default values are set and then when you import the first video file, its properties are transposed to the project settings.
The logic is thus: either users don’t really care about the project settings and the “Project Settings” dialog showing up when creating a new project overwhelms them, or the user is an experienced videographer, in which case they’ll know when they need to change the project settings and where to find them. A very nice touch is that when the project settings are changed automatically, an infobar appears, so the user has the chance of opening the project settings and correct them if need be. More details in T3161.
New project settings and rendering UI
The widgets in the project settings dialog and the rendering dialog were split into multiple tabs, to fit on 1024×768 screens. Unfortunately this required clicking the tabs to see or edit the settings. Moving the eye is faster than clicking so we looked into this and came up with a solution to get rid of the tabs and keep the dialogs as small as possible.
The preset selection UI is now composed of a ComboBox plus a MenuButton. This way the preset selection UI takes extra vertical space instead of extra horizontal space. We find it works pretty good. More details about how it works and more screenshots in this doc.
Keyboard shortcuts window
Jakub Brindza joined us as a GSoC student. The first step of his project is already done, a brand new keyboard shortcuts window built dynamically, to be able to support custom shortcuts. Next will be allowing users to customize the keyboard shortcuts.
Other noteworthy changes
The user manual has been updated to reflect the changes since we switched to the headerbar, about one year and a half ago.
The undo/redo removal has been undone.
We switched from AppImage to Flatpak to distribute our own builds. A big advantage is that due to Flatpak’s sandboxing we can use it for the development environment while previously we needed a separate complex script to take care of that.
* There was a very high chance of ending up with artifacts at the start of a clip with an inpoint.
This is the first blog post of a series of updates about our latest development efforts in GStreamer / gst-editing-services / Pitivi.
This post’s focus will be on MPEG transport stream, a format now nearly twenty years old, originally developed and still widely used for and by the broadcasting industry. In the mid-2000s, some people decided it would be a great idea to use this format in camcorders, stuffed a rather useless timestamp in there for good measure and started to ship AVCHD camcorders like it was the greatest thing since sliced bread.
It was not. See, most modern video codecs such as h264 rely on the notion of keyframes: to compress video streams as much as possible, most frames are encoded as their difference with the previous frame, we call these frames delta units. Sparsely distributed in the encoded stream are keyframes. These frames can be decoded without any reference to past frames, and when trying to seek in such a stream, decoding has to start from a keyframe and progress through all the delta units up to the requested frame.
Video editing implies accurate seeking, for example if you only want to include the 10 last frames of a 2-hour clip, decoding the whole file to obtain these few frames would be a pointless waste of time.
Failing to start decoding from a keyframe when seeking creates artefacts, garbled frames : the decoder is missing information to decode the delta unit, tries to provide a frame nevertheless and fails in doing so, until the next keyframe has been reached. Containers that are readily usable for editing contain information about the location of keyframes, in one form or another. This is not the case of MPEG TS, of which AVCHD is a subset. Locating the keyframes thus becomes a rather involved process, as one needs to parse the video streams in order to do so.
Backtracking to the introduction of this post, good news everyone ! We just did that, and here is a before / after video to demonstrate our changes. We can now ensure full support of AVCHD, enjoy 😀
The next two posts will be respectively focused on our refactoring of our video / audio mixing stack, and our ongoing work on gnonlin, our non-linear editing engine.
The Pitivi community is very happy to announce the availability of easy to use, distro-independent Linux bundles to test latest version of the application. This eliminates dependency problems and allows quicker testing cycles. Our entire stack is bundled, so the only requirement is glibc ≥ 2.13.
This is the first delivery of the Pitivi Fundraiser—as you can see, we are already well on our way to deliver what has been promised in our detailed planning. You can have a look at what is happening with the “daily build” bundles on on our Jenkins instance (main server hosting donated by Collabora—thanks!).
This does not only apply to us, of course: work that has been made for creating Linux distro bundles allows anyone to easily create bundles for their applications with Cerbero. This has not been merged just yet, but that should happen quite soon. If you want to bundle your app using Cerbero, do not hesitate to ask us, even if it should already be really straight forward!
We raised half of the amount we are targeting for the Pitivi fundraising campaign, and we are in very good shape to be able to deliver everything on time. We need your help to reach that target.
Please donate now to make sure we will be able to provide the community with the great video editing app it deserves!
Last week-end, part of the Pitivi Team went to the GStreamer Hackfest in Google’s offices in Munich to work with twenty other GStreamer hackers on various important technical issues. A big thanks to Google and Stefan Sauer for hosting the event! Keep your eyes peeled: we will soon blog the results of the work the Pitivi team has accomplished during the hackfest.
During the hackfest a very important milestone has been reached: the first GStreamer Editing Services, GNonLin and gst-python stable versions in the 1.X branch have been released. That means that these very central components of the Pitivi project are now considered stable.
While this backend work was essential to the beta release, we also want to specifically thank Alexandru Balut for his impressive involvement during the 0.92 -> 0.93 cycle. He provided an impressive amount of bug fixing and cleanup patches in Pitivi itself, and has greatly helped the project reach a beta state. Any inquiries regarding the 0.93 release codename must be sent in his general direction.
This release will be the basis on which we will start our work for our ongoing fundraiser. We’ve done that work in our spare time, and we’re excited about what we’ll be able to accomplish once we start working full time! Thibault Saunier has already been preparing bundles for the release, more on that in the next post!
Once again, you can help us in producing a rock solid stable release, by donating and spreading the message!
We hope everyone had a great week! We’ve had a rather hectic one, and hopefully that’s just the beginning. This is the first update for our fundraising campaign, be sure to check our blog weekly for more 😉
We are happy to announce that the GStreamer maintainers decided to show us their faith and support, by allocating 2 500 € to our project from GStreamer funds! This is great news for several reasons:
It’s obviously nice to get such an amount of money as it represents seven percent of the total needed to get a 1.0 release or, to put it another way, three weeks of full time development!
GStreamer is the central component of our architecture, and it is the one on which we plan to spend most of our time during the push to 1.0. Pitivi really is just the tip of the iceberg, to put things in perspective, it now only is a mere 25,000 lines of Python code, whereas GStreamer and its plugins represent around 1.5 million lines of code.Our work really benefits every other project that uses GStreamer (for example, accurate seeking in ogg files? That was us!), and it is meaningful to see the GStreamer maintainers acknowledge that “officially”, many thanks to them! And then many more for the road. They’re awesome and a big reason why we love working on Pitivi.
We really hope this donation will help everyone that cares about Open Source, be they individuals craving for flawless multimedia handling on Linux or companies interested in building products around GStreamer, to see that we are an integral part of the community, and that donating to the campaign is not only about getting a great video editor, but also about improving the core multimedia engine shared by most if not all the Linux distributions!
We would like to thank each and everyone of the 350+ backers that already donated to the campaign and helped us break the 10 000 euros bar during this last week. 11 000 € is a great amount of money, sufficient to cover our expenses for three months of full-time development! With your help, we already made it to a third of our first goal, and with your help we can make it to Pitivi 1.0 and beyond. Anything helps, be it blogging, tweeting and sharing on social networks, or getting the word out to journalists.
DistroWatch also decided to make us the recipient of their monthly donation, and granted us 280 euros, it’s a great honor for us to be listed among the previous recipients of that donation!
The dictionary doesn’t seem to agree that this word should exist, but it’s here nevertheless. Next week should see an interesting announcement for all the fans of Python, Romania and clean code, make sure to stay tuned on our twitter or to add this blog to your RSS feeds 😉
This is a very good example of what our developers can do! There has been some preliminary work on bringing slow and fast motion to GStreamer and Pitivi, and a plugin has been created to allow for frame interpolation, which means you and I with our regular 24 frames per second cameras will be able to get smooth slowmotion from Pitivi in the future!
All that work has not yet been merged and thoroughly tested, and we need your help to make it happen!
To help you understand the difference between regular and smooth slowmotion, here is a video showing both types side by side, created by Alexandre Prokoudine. The difference is quite stunning!
During the creation of the campaign, we debated what kind of perks we should offer. The thing is, we are not t-shirt creators, we are software developers and UI designers.
We believe people who give us money do so in order for us to develop a good software, and thus we tried to focus on perks that made real sense. What could we offer to the community that would help us in making the software that they truly want? Our answer to that question: a voice, simple as that.
Though we already have a very active community and listen to feedback from our users, we were missing a way to quantify the priority of feature requests for the people to whom our software matters enough to sponsor our work.
We decided on two types of perks we would offer: invitations to hangouts organized monthly (we’ll tell you more about that in a future post), and the subject of today’s post, our voting system!
We wanted to grant the possibility of voting to anyone who donated, from the lowest amount available, and decided to weigh the vote proportionally to the amount given, with steps at which the curve flattens a bit, to make sure people who can’t donate 300 euros still have a reasonable chance to have their voice heard.
Later I’ll post implementation details for those interested, on my personal blog. Suffice to say that it works, and more exciting that people are already making good use of it!
This brings me to the exciting news we want to share: we made the current vote results public! Obviously, as we’re in the early stages of the campaign, they’re not nearly as significant as they will be later, but we think it’s already interesting data, and you can have a look at them live right now .
Now to our own analysis of the data so far:
The first exciting figure for us is that even though we’re not yet guaranteed to reach a funding point that can put vote results into development (you can help us get there faster), one third of our backers already took the time to go through the form and rate features on the 0 to 10 scale, and we clearly expect that ratio to grow if we reach the 35,000 bar.
We interpret that as a sign that our voting system answers a real demand. This figure is a clear success in our effort to create sustainable community engagement to support responsive and dynamic Pitivi development, alongside the growing number of people who choose to put their faith in us and donate.
Some points in the feature ranking results caught our attention:
The clear first place of hardware accelerated decoding and encoding. This is really interesting to the engineers among us, who already salivate at the possible prospect of implementing it!It also goes to show that performance is critical to people using video editing software, and reassures us in our architectural choices: the decision to ally with GStreamer means a lot of the heavy lifting is done as part of a partner project that doesn’t have to be written by Pitivi developers from scratch. Instead, we contribute to GStreamer while also reaping the huge benefits of it — and that means we can focus better on the video editing side of our code (making sure dynamic pipelines work with hardware-accelerated decoders/encoders, adapting and extending our integration test suites to ensure it keeps on being true)
The very pragmatic second place of copy paste, a small but oh-so-helpful feature, which goes to show that our backers are sensible, productivity and detail-oriented people.
The low ranking of Windows and Mac ports, which is certainly due in part to the fact that awareness about our campaign is pretty much limited to the Free Software community for now.
Finally, something we don’t really know how to interpret on the spot, but that is interesting to remark nevertheless is that the three last spots are occupied at the time of writing by external project formatters, such as Final Cut projects.
I’ll repeat that these rankings are absolutely not definitive, as already existing backers can change their votes and new backers should hopefully continue to give their opinion on what matters to them.
The conclusion is: “Don’t like these rankings ? Donate and you can contribute in changing them!”
We’re really interested in your analysis of these early results, and hoping that discussion will occur about them in the comments section or on our IRC channel (#pitivi on freenode)!
Today we’re thrilled to announce a crowdfunding campaign to support the development of Pitivi!
We have made the choice not to use one of the major crowdfunding platforms such as kickstarter for multiple reasons, and instead partner with the GNOME foundation, which is ideologically aligned with us and will support our financial infrastructure.
We are proud of that partnership, as we share their objective of “creating a free software computing platform for the general public”, and the foundation is excited as well:
“GNOME is proud to host the Pitivi campaign. Pitivi fills a real need for stable and approachable high quality video editing. Its software architecture and UI design share the same sleek and forward-thinking approach that we value in the GNOME project.” — Karen Sandler, executive director of the GNOME Foundation
With that campaign, our aim is to provide everyone with a rock-solid Free Software video editor, based on the awesome technology that is GStreamer. We have spent a lot of time working on the campaign website, and it holds a lot more content than a simple blogpost could.
We know that what we want to do is the right thing, and requesting money for quality and stabilization first is the correct and honest thing to do. We obviously encourage you to donate to the campaign, but we also hope that you will be willing to spread the message, and explain why what we do is important and good.
Free and Open Source video editing is something that can help make the world a better place, as it gives people all around the world one more tool to express themselves creatively, fight oppression, create happiness and spread love.
Hoping you’ll spread the love too, thanks for reading !