Go check the latest news. This page serves for historical purposes and is not updated anymore.

October 11, 2020

Pitivi 2020.09 — Hocus focus

The Pitivi team proudly presents Pitivi version 2020.09, a new milestone towards the most reliable video editor.

New features

Since the 2014 fundraiser and until Pitivi 0.999 released in 2018, we included only critical features to focus on quality. For example, the proxy functionality which allows precise editing by seamlessly using the optimized media when the original media format is not supported officially.

Life and GSoC happens and we developed many good features over this period. Most of these originate from the Google Summer of Code program in which we took part, but not only. The new features came with accompanying unit tests and they have been merged only after careful code reviews. Even so, we kept them in the development branch.

This approach led to extra work for taking care of two branches. In addition to a “stable” branch out of which we were making releases, we also maintained a “development” branch in which we were merging cool features. Luckily, despite not much appearing to be happening with the project due to releases containing only bug fixes, contributors kept showing up, and not only because of GSoC.

Since the previous release we came to our senses and reconsidered the earlier decision. Pitivi 2020.09 includes a ridiculous number of new features, for your delight. Read the full list below and get ready to be blown away by what our contributors built.

Quality

The user survey we conducted in 2013 revealed the most important point was to have a “stable as hell” basic editor. Since the previous release two years ago, we fixed the last outstanding bugs in GStreamer Editing Services (GES), Pitivi’s reusable video editing backend.

At this point, the extensive GES and Pitivi unit tests and the gst-validate testing framework developed for GStreamer/GES allow us to make changes without being too afraid of introducing regressions. Thanks to the quality assurance we have in place, we are now switching to a date-based versioning scheme for Pitivi. The intention is to release often what we have at that point and make gradual changes.

Even though there won’t be a Pitivi 1.0, after 15 years of hard work we are proud GES has reached the “1.0” level. We are very happy to finally reach this essential milestone in the project life!

This was possible thanks to contributions from Igalia who has been sponsoring the development of the GStreamer Editing Services by stabilizing it and implementing many features such as the integration with OpenTimelineIO from Pixar, implementing timeline nesting, and clip speed control (yet to be leveraged in Pitivi).

We’ll be looking for ways of creating a constant stream of money to fund development by drawing interest from institutions backed by public money. Until this will happen, if ever, we’ll play with occasional fundraisers for improving stability. More about this in a separate blog post.

What’s new

This release includes lots of new features, originating from GSoC internships spanning four years, from University of Nebraska-Lincoln’s SOFT-261 class Spring 2020 and from individual contributors.

GSoC 2017
  • A plugin system allows extending the Pitivi functionality medium-term, targeted for teams of editors.
  • A developer console plugin allows interacting with the project in a Python console.
  • Mechanism for supporting custom UI for effects issues of the automatically generated UI.
  • Custom UI for the frei0r-filter-3-point-color-balance and alpha effects.
  • Easy Ken-Burns effect.
GSoC 2018
  • The new Greeter perspective replaces the Welcome wizard dialog and allows a slick selection of a recently opened project.
  • When being resized, the Viewer shows the percent of the actual widget size in relation to the project video size.
  • The Viewer size snaps at 50% when being resized.
  • Scaled proxies if optimized media is too much for your machine.
GSoC 2019
  • Timeline markers.
  • Support for nested timelines by importing entire XGES files as a clip.
  • The Effects Library has been redesigned to allow quick access to effects.
  • Ability to favorite effects in the Effects Library.
  • Improved workflow for adding effects.
  • The refreshed clip effects UI allows working on multiple effects at a time.
GSoC 2020
  • Refactored Media Library to use the same logic for the different view modes.
  • Refactored Render Dialog UI to avoid overwhelming people. Tell us what you think about it.
University of Nebraska-Lincoln’s SOFT-261 class, Spring 2020
  • Restoring the editing state when reopening a project.
  • Safe areas visualization in the Viewer.
  • Easy alignment for video clips.
  • Composition guidelines in the Viewer.
  • Solid color clips.
  • Ability to mute an entire layer.

Individual hackers

  • Custom UI for the frei0r-filter-alphaspot effect.
  • Interactive Intro for newcomers to get familiar with the UI elements.
  • The action search is a shortcut to everything possible in the timeline, if you can find it. Press “/”.
  • Ability to hide an entire layer.
  • New keyboard shortcuts for pros.

Under the hood

Since the Pitivi 0.15.2 release that came at the time of our 2014 crowdfunding campaign, we have basically changed everything under the hood, with too many bug fixes to count:

  • We rewrote the timeline canvas twice due to the changing technological landscape around us.
  • We’ve redone the clip transformation UI in the viewer twice.
  • We’ve redone the undo-redo system.
  • We’ve redone the Media Library.
  • We’ve redone the Effects Library.

Please see the corresponding 2020.09 milestone for details.

Download

You can install Pitivi 2020.09 right away with flatpak. Follow the installation instructions from flathub.

What’s next

We keep the highest priority issues in the 2020.12 milestone. Basically a mix of bugfixing, cleanup and features.

Thanks

Many thanks to all the contributors!

August 31, 2020

Google Summer Of Code 2020 Final Report

GSoC @ Pitivi During this summer I improved Pitivi’s Media Library. The work included both refactoring and adding new functionalities. My proposal has a detailed roadmap on the goals I set to achieve during this summer.

Initial cleanup

To prepare the codebase for introducing new modes of displaying the clips in the Media Library, I refactored the code to unify the iconview and listview modes of the Media Library into a single responsive grid view. The two modes were using different types of widgets, requiring duplicate logic. Now both iconview and listview modes are powered by a single Gtk.FlowBox widget. Issue #1343

Link To Submitted MR. ( merged )

Link To Related Blog.

Shifting the asset action buttons to a new action bar

The Tagging functionality is accessed through a new Tag button, for which we needed to make space since the MediaLibrary’s toolbar was already very crowded.

medialibrary before the introudction of new action bar

We decided to group all the buttons related to the selected clips on a new toolbar at the bottom of MediaLibrary. Initially we came up with a design of a floating toolbar at the bottom using Gtk.Overlay. We went through a number of iterations on various ways to place it and settled on using a standard Gtk.ActionBar which is designed to present contextual actions, exactly what we needed.

medialibrary after the introduction of new action bar

Link To Submitted Commit.

Tagging clips in the Media Library

I introduced a new Tag button which reveals a Popover for tagging the selected clips. A clip can have multiple tags. Multiple clips can have common tags.

Tagging Feature

The Gtk.Popover shown by the Tag button displays all the tags using a Gtk.ListBox. The state of each tag can be controlled using a Gtk.CheckButton. A CheckButton is “checked” when all the selected clips have the corresponding tag, “unchecked” when none of the clips have the tag, and “inconsistent” when only some of the clips have the tag. Clicking the CheckButton takes it through the three states.

A Gtk.Entry allows to specify a new tag to be associated with all the selected clips.

An “Apply” button saves the changes in the project. The Apply button remains disabled unless there are changes to be applied. It does not permit creating a duplicate tag. Note: After applying the change via the Apply button it is not written in the project’s xges files. To do so we need to save the project. Taking advantage of the fact that the GES.UriClipAsset is a GES.MetaContainer, we store the tags under the individual clip’s metadata ( “pitivi::tags” ). When saving the project, the tags are thus saved in the project’s xges file. While working on saving and retrieving asset metadata we encountered a minor bug in GES because of which we were unable to retrieve the saved metadata from a reloaded project. So we worked on a fix before moving on.

I introduced new test cases exercising the UI for addition and removal of tags under several scenarios. Issue #537

Link To Submitted MR.

Filtering of clips based on their tags

After completing the Tagging feature our plan was to utilise it for filtering the clips. We worked on extending our current search functionality to include searching by tags. Luckily the search bar in MediaLibrary is composed of Gtk.Entry which has a convenient method set_completion to assign an Gtk.EntryCompletion to it.

Gtk.EntryCompletion allows us to use Gtk.TreeStore to provide suggestions based on the text or key entered inside the Gtk.Entry. We already had a global set of tags maintained in the MediaLibrary for the tagging feature. We used it to fill the model required by Gtk.EntryCompletion. We utilise it’s built in Autocompletion and Popover to manage our filtering operation using tags.

Filtering clips based on tags

Link To Submitted MR.

Work To Be Done

The work in https://gitlab.gnome.org/GNOME/pitivi/-/merge_requests/318 is currently under review, polishing and updating it as per the reviews would be my priority. The introduced test cases for Tagging feature can be reduced and extended to cover more scenarios.

One of the extended goals was to introduce filtering clips by date, we need to finalize the roadmap of this feature and my goal would be to implement it.

Updating the user manual to mention the Tagging Feature is also a task that I intend to do.

I am grateful to

Thibault Saunier and Alexandru Băluț for all the guidance and support they have given me throughout my time working at Pitivi, they were always present to solve so many of my doubts patiently. Without their support this much work would not have been possible.

August 29, 2020

GSoC 2020 @ Pitivi: Work Product

Overview

My GSoC 2020 internship project was improving the usability of Pitivi’s Render dialog. Below is a detailed summary of the work done during the last three months.

Refactoring the Render Presets’ selection

The previous UI for selecting a render preset was being constructed dynamically. The same mechanism is used to also construct the audio and video selection preset UI in the project settings dialog.

Can you even notice where the render Preset option is in all the clutter?

Old Render Dialog-1

We decided to move forward with a button which shows the current preset. When clicked, it opens a Gtk.Popover which lists the available presets. The presets listed in the popover include a relevant icon and an informative summary, making it an easy choice for the user. Thus I fixed issue #1813.

We mostly cared about rendering a project to be uploaded to an online sharing service such as YouTube, Vimeo, etc., so there are not many other options at the moment.

A custom icon is used for Custom profiles.

Updated Render Dialog with popover

Through multiple iterations, we fine-tuned the UI so it looks nice and clear, improving the User Experience.

MR: link

MR status: Merged.

Addition of path property in Gstreamer Encoding-Target

Previously when a render profile was deleted, it was just marked as such. While at it, I took the opportunity to properly delete them. Unfortunately the path of the file where a GstPbutils.EncodingTarget object originates was not available.

I added a new path property to GstPbUtils.EncodingTarget and populated it when the object is saved or loaded.

MR: link

MR status: Merged.

Hiding the advanced render UI in a new “Advanced” expander

The many settings displayed on the render dialog were intimidating to both new and seasoned users. Since many will never be interested in the advanced settings, I introduced an expander which hides the detailed settings of rendering dialog, at the same time keeping them easily accessible.

Also, I moved the Folder and Filename sections at the bottom, to give more prominence to the render preset which is now at the top. I made the UI follow the GNOME Visual layout for an attractive and intuitive design.

MR: link

MR status: Merged.

Addition of Quality selection for supported encoders

In the video rendering process, there is a tradeoff between quality of the rendered video and the size of the video and the time it takes to render. If the user requires the video to be in high quality then the size of the video also increases.

To simplify the user’s choice, a Gtk.Scale widget has been introduced for specifying the desired render quality. The quality setting affects different parameters for different encoders, but this is done in the background.

Updated Render Dialog with Quality Scale.

Updated Render Dialog with Quality Scale -2.

MR: link

MR status: Work in Progress.

Work to be done

Merge request !323 is still being reviewed in the final stages, and shall be merged soon.

We can add more presets, such as high-quality archiving to be able to dispose of the original video material.

We can show a summary of the render settings so the user can quickly check them and enter in the Advanced settings expander if something looks bad.

GSoC 2020: Pitivi: Work Product

This post is a summary of the work that has been completed during the GSoC 2020 period for my project, Object Tracking. The project consisted of implementing an Object Tracking UI in Pitivi and the associated tracking functionality in GStreamer.

cvtracker GStreamer element

flatpak: add opencv_contrib

I began by adding the opencv_contrib module to the opencv installation for the Pitivi development environment. opencv_contrib contains the library with the tracking algorithms.

OpenCV Tracker Element for Object Tracking

This merge request introduces the tracking functionality in the gst-plugins-bad package.

Previously the opencv plugin was not being built due to the unavailability of the headers. This patch fixes the problem, ensuring that the headers are detected for the correct version of opencv and the plugin is built.

In the next commit: opencv: add cvtracker plugin, I implement the cvtracker element as part of the opencv GStreamer plugin and set up the associated tests to ensure correct working. The next commit: meson: add opencv/tracking header requirement ensures that the tracking library is available before building the plugin.

I implemented an additional feature to draw a rectangle over the tracked object. This will come in handy during the testing phase and for live tracking in Pitivi. opencv: cvtracker: add draw property

A brief explanation of the cvtracker element can be found on my blog post: cvtracker: OpenCV object tracking plugin

Tracker Perspective

With the GStreamer element for tracking completed, the next stage was to implement a user-friendly UI for object tracking. The new Tracker Perspective replaces Pitivi’s main window, allowing to select an object on the viewer and track it. If the chosen tracking algorithm fails to track the object correctly, the tracking can be redone from a corrected position.

The work done on the Pitivi side currently resides in the Merge Request

A brief explanation of tracking objects can be found on my blog post:

Pitivi: Object Tracking

As the project progressed, we iterated and made a lot of UI improvements. A demo with the explanation can be found here: Pitivi: Edit Object Tracking

Screenshot of the TrackerPerspective UI

Selecting an object from the viewer

Live tracking in TrackerPerspective

Processing the tracked objects

`Cover Object` button to add effects and track objects

Cover Object Popover

Cover effect on clip

A tracked object can be covered with a colored rectangle on a clip in the timeline. This can be done easily through the “Cover Object” button in the “Clip Properties” middle pane shown when a clip is selected.

When an Asset from the Media Library is dragged and dropped on the timeline, it becomes a Clip. A user can create multiple Clips from a single Asset.

The tracked objects belong to the Asset. That means if an object is tracked, it’s available to all the Clips backed by the particular Asset. The tracked data is then applied to the properties of an Effect applied to the Clip to obtain the ‘cover rectangle’. Clips can have object effects independent of each other.

If a tracked object is deleted from the Assed in the TrackerPerspective, the effects associated with that object will be deleted from all the Clips of that Asset. The below figure shows the situation when ‘Object 2’ is deleted.

Technical Note: Taking advantage of Assets being MetaContainers, we store the Objects’s tracking data as a pitivi::tracker_data metadata item. The tracking data is saved in the Project’s .xges file by GES when the Project is saved.

Project Status

The tracker element and Pitivi UI are complete, as demonstrated in my blog posts. However, there are 2 major bugs in the feature for adding effects to the tracked objects.

The first bug is when the user adds the effect for two objects, one with more tracking data than the other, the video track of the clip gets disfigured. This might be due to no available tracking data before the start, which causes the tracking box (red box in this case) to be shown at the bottom-right corner until it receives its first tracking data point. Here’s a small demo of the bug: YouTube

The fix for this bug is to add a zorder property to the gescompositor element of the effect and to set the tracking data point to some random far away point before the beginning of the actual tracked data points.

The second bug is when the user adds the effect for an object and then resizes the clip in the viewer, the effect doesn’t follow. Here’s a demo for the bug: YouTube

The currently discussed solution is to re-adjust the tracking data every time the user makes a change to the clip video track in the viewer, by resetting the ControlSource.

August 16, 2020

Pitivi: Edit Object Tracking

My last post was about adding a feature to track objects. But sometimes the algorithm doesn’t track the object 100% correct, so in this post, I present to you a new update which lets the user edit the tracked data easily in the Pitivi Tracker Perspective itself.

Demo

See the feature in action. YouTube

In the video, the user selects a clip and goes to the Tracker Perspective, by clicking on the “Track Object” button. Now, the user selects the object to track and chooses the algorithm before tracking. Pitivi tracks the object for the rest of the clip.

But wait, the user has accidentally chosen only a portion of the object. They can correct this by seeking to a point in the tracking and selecting the object again, this time, they get it right :) After the tracking is completed, the tracking data is updated to accomodate the updated tracking co-ordinates.

Similarly, we can correct faults in the tracking.

UI improvements

Cursor changes to crosshair when hovering on the viewer

Track Object button is inside Blur Object popover

Start position of the tracked object shown as a marker on the seekbar

Added an infobar to show instructions

Info bar disappears on choosing an object

Further developments

A feature to add an effect to the tracked objects is in the development stage. The tracked objects will be shown in the “Blur Object” popover. The user can add an effect by clicking on the object. More on that in another post. :)

July 28, 2020

Pitivi: Object Tracking

I’ve been selected as a student developer at Pitivi for Google Summer of Code 2020. My project is to create an object tracking and blurring feature.

In this post, I introduce a feature in development which allows the user to track an object inside a video clip.

Object tracking in action

Before diving into the aspects, let’s see it in action. YouTube

In the video, the user selects the clip to be used and clicks on the “Track object” button. In the next screen (tracker perspective), the user chooses a frame and selects the object to be tracked using a drag-and-drop motion. The user then sets the tracking algorithm and initiates the tracking. Live tracking is displayed. The tracked object appears on the left pane. The user has the option to delete the tracked object.

Internals

The cvtracker is a plugin from gst-plugins-bad project (which is also a part of my GSoC project). It allows us to track the object by running the clip through a pipeline. The tracking data is available through the bus and buffer metadata.

The tracking in pitivi is implemented using a pipeline, which runs the clip and feeds it to the cvtracker. We extract the region-of-interest (ROI) data from the buffer.

An Object Manager class stores all the tracked objects in a clip. Technically, the object data is saved to the asset metadata. So every clip that gets generated using the asset has access to all the tracked objects.

Tracking data

For receiving the tracking data from the cvtracker, we use fakesink with the properties: fakesink name=sink signal-handoffs=TRUE.

Then we connect the handoff signal to the callback function:

def __tracker_handoff_cb(self, unused_element, buffer, unused_pad, roi_data):
       video_roi = GstVideo.buffer_get_video_region_of_interest_meta_id(buffer, 0)
       if video_roi:
           roi_data[buffer.pts] = (video_roi.x, video_roi.y, video_roi.w, video_roi.h)
       else:
           self.log("lost tracker at: %s" + str(buffer.pts / Gst.SECOND))

Further developments

There’s more coming! Sometimes the tracking can be a little inaccurate, so we’re working on a feature to adjust the tracking of an object. Basically the user can manually adjust the tracking data using a simple and user friendly interface, integrated right into the tracker perspective. More on that in another post.

July 14, 2020

Refactoring Pitivi's Media Library

Since my GSoC project is about improving Pitivi’s Media Library and introducing new features to it, the first task was to clean it up.

To display assets the Media Library used a Gtk.TreeView widget to show a detailed list view and a Gtk.IconView widget to show a simpler icon view. Some major drawbacks with the previous implementation using two separate widgets are:

  • We had two widgets in memory ( we toggled their visibility to switch between the list view and the icon view )
  • We had redundant code and callbacks for the same signals ( one to handle Gtk.TreeView and the other for Gtk.IconView )
  • Any new feature would require us to implement it in two widgets, using two widgets also brought their native bugs with them

What we needed was a single widget that could support both views, saving us from all the aforementioned drawbacks. Luckily such a widget called Gtk.FlowBox was introduced in GTK 3.12, six years ago.

The plan was to only use Gtk.FlowBox under the hood to display both list view and icon view, hence refactoring the already present logic into Gtk.FlowBox was the only task.

Now let us look at some technical details around how we’re using Gtk.FlowBox and how we refactored the code.

First leap:

One idea was to first refactor listview and then iconview into Gtk.FlowBox. This seemed a good approach at first as we were breaking a big task into smaller steps, but soon an issue came up.

Gtk.FlowBox uses Gio.ListStore, while Gtk.TreeView and Gtk.IconView rely on Gtk.TreeModel. If we kept one of the previous widgets we would have to keep the TreeModel along with it too. This would just add unnecessary tasks to the project, we would have to add some temporary methods to parse and sync both the models. So after a brief discussion it was decided we simply go all in. There was no actual need of breaking the task in two parts in the first place.

Setting up Gtk.FlowBox for the first time:

I started by introducing a minimal Gtk.FlowBox widget and commenting out all the code that powered the previous views. Initially it took some time to get used to FlowBox and figuring out on how to actually use Gio.ListStore with Gtk.FlowBox.

The way we toggle between views:

In the previous approach we were switching between the Gtk.TreeView and Gtk.IconView widgets having one of them visible at a time. Initially I replicated a similar approach for FlowBox, keeping two widgets per item.

We preferred to keep the logic simpler and instead to recreate the widgets when the view mode is changed. This approach was easily possible with FlowBox by re-binding the model and specifying a different createwidgetfunc. This also saved us from wasting memory in storing two sets of child widgets.

Setting up Drag and Drop along with Rubber Band selection:

This task took a significant amount of time. In my first implementation of Drag and Drop the dragging wouldn’t work at all, instead multiple items would get selected in the direction of dragging. At first I didn’t look much into the cause behind this behaviour, my initial stance was maybe I was not implementing the drag and drop correctly in Pitivi. After a lot of debugging when nothing worked, I realized I should try implementing it in a minimal Python script first. This is when I noticed by default in FlowBox if we drag over it’s children they come under rubberband selection.

The first subtask was to stop this behaviour because in Pitivi the users would prefer dragging the asset to timeline by default over selecting multiple assets.There was no clear way how to differentiate between dragging as in drag and drop and dragging in case of rubberband selection. To get a better idea what’s going on, I looked into the codebase of Gtk.FlowBox where I found it used Gtk.Gestures to govern the rubberband behaviour but I still couldn’t find anything on how to distinguish it from a drag and drop operation.

In Pitivi’s previous implementation Gtk.IconView had both of these operations perfectly working together. A major point I came across while playing with it was that one could only initiate the rubberband selection from an empty space. Dragging over an asset would simply initiate a drag and drop operation. I then decided to read the codebase of Gtk.IconView to better understand how to implement/replicate it in Pitivi.

Now we differentiate between drag & drop and the rubberband selection by controlling the propagation of the “button-press-event” signal. In case if we propagate the signal further by returning True in the button-press-event handler we say yes to rubberband selection, which means everything you drag upon is selected. If we don’t propagate the signal by returning False, we block the default behaviour and drag and drop comes into play.

How do we decide whether to propagate the signal or not ? This is inspired by Gtk.IconView, we simply check if there is any asset under the cursor when we start dragging, if yes the dragging is meant for a drag and drop operation so we block the propagation of the “button-press-event” signal. Otherwise we propagate the signal which results into rubberband selection.

P.S. A shout out to the last implementation, the codebase was pretty readable and I actually never had to go through any struggles in understanding what was going on in the previous implementation and that was a major booster !

What’s next in Pitivi ?

Now with the upgraded Media Library we are all set to introduce new features ! The first one we are working on is Adding Tagging functionality to clips which will allow us to display the assets by tag as a Folder View.

This feature empowers Pitivi’s user base to categorize their assets in the Media Library. An asset can have multiple tags. Multiple assets can have common tags. Assets can be filtered based on their tags by searching.

The first step is to extend the current asset properties dialog to include a Tags property and a proper way to add and store new tags.

tags-in-pitivi The second step is to extend it to manage possible operations on tags in case multiple assets are under selection!

Last step would be to introduce The Folder View, which shows the assets into folders based on their tags.

July 05, 2020

Pitivi: Making the Render dialog usable: Render profiles

GSOC Pitivi

It’s been around two months when I officially became a GSOC student Developer at Pitivi and now, the 1st coding month has completed. Although we had a structured proposal to follow during GSOC, we adapted as per what looked much more suitable and made more sense. If you have been using Pitivi, you are in for a surprise.

Old Render Dialog-1

The first task we were looking forward to was replacing the Render Settings Dialog with a Render Perspective. However, after trying different designs, we thought of keeping the original design and include something new to it. To make the settings much more intuitive, we moved forward with working on the presets section of the render settings.

Old Render Dialog-2

Previously, the preset selection consists of a combo box, to choose the preset profile to apply. We were thinking of changing it to something similar to what DaVinci Video Editor tool presents, that is, a bar with all preset profiles available. But there was limited space in this design which created problems with providing more info to user and making most out of the preset selection menu, therefore, we decide to innovate a little.

Da Vinci Preset bar

My mentor, Alexandru suggested me this great design with popular Gtk Popover. As compared to the previous design, this made us present much more information to the users about these profiles in lesser space and made the design easier to interact with for users. We replaced the combo box with a button which highlights the selected profile along with the corresponding icon. When this button is clicked, a list of preset profiles is presented using the GTK Popover. For every preset profile, we have included an icon along with a brief description of the profile and path to where the profile file is saved.

Updated Render Dialog-1

We asked for the help of GNOME’s Design Team and Pitivi community members for their feedback on the new design. The icon is an important part of each profile as it’s making the profile easier to identify visually. For example, for ‘YouTube’ profile, we have used the YouTube branding logo, thanks to YouTube for allowing us to use the logo. While for other profiles we have used the GTK-icons.

Updated Render Dialog with popover

To be able to allow the user to remove an existing preset, we also added another property path to the GST-plugins-base code in file encoding-target.c. You can check the MR here. So, if you have been working with this project, feel free to use it as per your need.

I have learned a lot during this period and hope to learn more over the upcoming months. It feels great to know that my work would help thousands of Pitivi’s users. Looking forward to you trying these features out and give me feedback! Thanks!

May 20, 2020

Playing back arbitrary frames with appsrc

If you have used GStreamer you may have used source elements like filesrc or v4l2src. Both of them use an existing source to play back a video, for example, the former takes as an input a video file from the source and the latter takes input from the camera. But, imagine you want to create a video by hand, something like. For example, videotestsrc, the element that displays a test (card) pattern, creates this pattern by filling a buffer by hand.

I will not talk about creating an element similar to videotestsrc. I will show an example program in which you tell programatically to GStreamer what to display at a given timestamp or frame.


The following example, will display

appsrc-example-colors.gif

  • from second 0 to 1: a blue frame
  • from second 1 to 2: a green frame
  • from second 2 to 3: a red frame

and repeat it for the next frames.


First, in line 104, we use the appsrc element, this element will allow us to push buffers by hand. We need to specify the caps we will use: caps=video/x-raw,format=RGBx,width=640,height=460:

Now in line 108, we connect to the signal “need-data”, which will be emitted as soon the appsrc internal queue starts running out of data. Because initially there is no data in the queue, it will be emitted as soon as possible. When this signal gets emited, we will start pushing data (in this case the frames of solid blue, green and red colors), and this is what is done in the function push_data of line 24. But before that, see that if we would not have connected to the “need-data” signal, we would have seen a black screen.

In line 109, we connect to the signal “enough-data”. This signal will be emitted when the appsrc inetrnal queue size exceeds the maximum allowed queue size (given by the property “max-bytes”).

For this example, I should haved probably increased the “max-bytes” property since the queue maximum size will be always exceeded. I will left that for you. The queue maximum size will be exceeded because we are pushing frames of 640 * 460 * 4 (width * height * 4 [RGBx] channels) = 1177600, and the default queue “max-bytes” property is 200000.

Ok, let’s go to the signal handler of “need-data”, line 24, the function push_data. Here is the interesting part. In line 35, firstly a buffer is allocated with the size of width * height * 4. Then, in lines 36-37, I have to timestamp the buffers. The first frame will have a timestamp of 0; the second frame, of 1 second; the third one, of 2 seconds… and so on. The duration assigned, in this example, is of 1 second for all the frames. This will make to play back 1 frame for 1 second, then the next second, the other frame and so on. Try playing with timestamp and duration and you will change the rate at which these frames are displayed.

Now the part were we start to write data to the buffer starts. We have to map the buffer in GST_MAP_WRITE mode for that (line 40). Then we start to write data. I picked RGBx to make it easier to write data, so I can cast the data as guint32 array and assign each item in the array to a color (lines 44-46). See that guint32 has 4 bytes, but we are just using 3 colors: in RGBx, the x “channel” is ignored.

Once the buffer is filled, we need to emit the “push-buffer” so the buffer is taken by the appsrc element. If we do not do that, we will see a black screen.


That is all for now. Sorry if there are things not used in the code, this is an old example and I did not have too much time to change it.

Now as task, try this with RGB or other colorspaces from here here.

I made this very quick and small example when working on a MR for gst-plugins-base to be able to apply whatever effect just in a region of a given frame (GstVideoRegionOfInterestMeta). I needed to see if what I did worked in videos without GstVideoMeta like in this example.

May 09, 2020

Presenting Our Google Summer of Code Students!

Google has published the list of students accepted in the Google Summer of Code program. The accepted students work on open-source software. Pending monthly evaluations, the students receive a stipend from Google. Like last year, we’re mentoring three students!

Abhishek Kumar Singh  will improve the Media Library. The current implementation will be initially simplified to deal with a single Gtk.FlowBox container. Asset tagging will provide the info to display in a new Folder View. The stretch goal is to display the assets by date.

Ayush Mittal will improve the Render experience. The current UI will be simplified, allowing the user to select a meaningful preset. Specifying the export quality for the officially supported encoders will be possible using a slider widget. The advanced options will still be available but not directly visible.

Vivek R will implement face/object tracking and blurring. A new GStreamer plugin will allow tracking a specified region in the video using OpenCV. The obtained tracking information is presented to the user to be reviewed and adjusted in a new UI Perspective. The user can apply the adjusted positions to a blur effect applied to the clip.

Please get in touch if you are interested in working with us. You can find us in https://matrix.to/#/#pitivi:matrix.org

May 02, 2020

Pitivi applies to the Season of Docs

The Pitivi video editor is based on the GStreamer Editing Services library (GES). Various projects use GES to manage audio or video projects and export the project to a new file to be distributed.

Pitivi is developed in very close contact with GES. Both Pitivi and GES would benefit a lot from better documentation.

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. Read below the project ideas if you are interested in working with us!

UPDATE: Pitivi is taking part in the Season of Docs under GNOME’s umbrella. If interested to update Pitivi’s user manual check the Update app help project idea and see below for details.

Project ideas

GES: 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 keep track of them so they can be fixed. 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 directly 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.

Pitivi: Update the user manual

The user manual is available both online and in Pitivi by pressing F1.

The latest Pitivi features should be documented in the user manual and the current content should be brought up to date.

The user manual is kept in the Pitivi git repository as mallard files.

How to contact us

If interested, get in touch with us on Matrix, so we can prepare. You are expected to ask a lot of questions.

 

August 26, 2019

Google Summer of Code 2019 Final Report

August 25, 2019

GSoC 2019 Final Report

image

PiTiVi Logo.svg

This year I worked on Pitivi, an Open Source Video Editor. With GSoC coming to an end, this post is a brief summary of the tasks that were done during the period, the things that were implemented, the work that is ongoing and the future plans that are left to do.

My project involved implementing Nesting Timelines in Pitivi, such that the clips can be easily nested to form one single clip.
Here is the project proposal:
https://drive.google.com/open?id=1jGJN2r6m7kiUkgbO5dCzOj7QY5G6rFzi


The Work Done:

Currently a Nested Timeline can be edited from Pitivi. Choosing to edit the clip starts another Pitivi instance with the same clip inside which can be edited as desired by the user and saved. On focusing back to the main window the clip is updated in the Media Library and the Timeline with the changes committed.

Links

Pitivi:

1) previewer: Allow generating thumbnails for assets

https://gitlab.gnome.org/GNOME/pitivi/commit/7473ce51f93a4d145eb8c97993ba3f3e7b123b34

2) previewers: Split VideoPreviewer logic into ImagePreviewer

https://gitlab.gnome.org/GNOME/pitivi/commit/abcdcc802f7e2ce52fbe367fa837a27ee837261d

Gst-Editing-Services:

1) tests: Implement nested timelines tests

https://gitlab.freedesktop.org/gstreamer/gst-editing-services/commit/ad6d1964af89a446e3df6cccce81c0d291ab1e11

2) tests: Add ges-sample-path-recurse with projects location

https://gitlab.freedesktop.org/gstreamer/gst-editing-services/commit/147cbcd6e1d41f98fb3f04f7a51d2893218b4e13

Gst-Integration-Testsuites:

1) added check_seek_on_nested_clips and check_seek_on_nested_timelines scenarios

https://gitlab.freedesktop.org/gstreamer/gst-integration-testsuites/commit/b00f6696d2d0a6dfd8a9628e393629339160e044

Ongoing Work:

Currently I am working on making the thumbnails of the updated clips appear properly on the timeline in Pitivi.

1) Opening another Pitivi instance for editing nested timeline

https://gitlab.gnome.org/GNOME/pitivi/merge_requests/197

Work left to do:

Now we can edit a nested timeline in Pitivi but I still have to implement the ability to create nested timelines from within Pitivi.
We also have to disconnect the additional Pitivi instance which appears, such that the user doesn’t go back into the Greeter Perspective.

Conclusion:
This summer I had an entirely new experience about software development, and in these few months I learnt volumes about the entire process needed to implement features in a software. It was the first time I tried these waters and it was challenging for me and sometimes quite frustrating, being a beginner, but my mentor’s and the communities’ support kept me afloat. I am glad that I had this opportunity which in just a few months helped me explore so much. Now looking back I can clearly see the line separating my skill before and after this 3 month period. Still there is a lot more to explore and learn. I will be continuing to contribute to Pitivi and be in touch with this great community.

Finally, I would like to thank my mentors Thibault Saunier and Alexandru Bălut for guiding me and patiently watching over my progress. They have taught me lot and I will continue with them the pursuit to make Pitivi better.

GSoC: Final report

Google Summer of Code 2019 has come to an end. This post is part of my final submission. It summarizes my contribution to Pitivi, providing links to my work.

My proposal consisted on a interval time system with different applications for Pitivi video editor. Originally, one of the applications would be to be able to set up markers at selected positions in the timeline, to store user metada.

After the first discussions it was clear that the core of the whole problem would be to implement the markers abstraction in GES (GStreamer Editing Services). They could store the information about position and duration needed. This was the base of my work.

Following are the links to my work. They are two contributions, one in GES and one in Pitivi, with all my code, fully functional. They implement a markers system in Pitivi, easily expandable.


GES markerlist class

My work in GES is co-authored with my mentor, Mathieu Duponchelle. It includes the new classes GESMarkerList and GESMarker, and tests for them. It is already merged.

GESMarkerList allows to have a list of GESMarker in every class that implements GESMetaContainer. Its API includes methods for create, serialize and deserialize a GESMarkerList, and for add, move, get and remove GESMarker. Also include signals to notify this operations.

The class GESMarker implements GESMetacontainer. It has a position property.

A set of new tests checks that everything works fine.

Link: GES markerlist class


Pitivi markers

My work in Pitivi is ready to be merged. It includes the new module ‘markers.py’ with the classes MarkersBox, Marker and MarkerPopoper. They uses GESMarkerList and GESMarker to hold the data, and Gtk to build the interface.

The class MarkersBox is used in the timeline. It’s an event box, zoomable, that has a layout to display Markers and supports different operations over them. It has a GESMarkerList.

The class Marker represents an individual marker, with a GESMarker and its interface. MarkerPopover creates a context popup menu that allows the user to insert text data in the GESMarker.

Every operation in this classes is undoable and there is a set of new tests to check everything.

Link: Pitivi markers


FUTURE

I want to keep working on this project. My proposal has revealed more complex that I thought at the beggining, but my skills and knowledge had improved over this time. I worked on very different parts of the project, all connected together. From the library bases to the interface, passing through the testing and the undoable/doable parts. All new matters to me.

I think this work represents a strong base to keep working on and a great approach to how multimedia and video editors work. Next steps would be to go back to GES and implement a duration property in GESMarkers, to be used in Pitivi to define time intervals.

Of course, I have to say thank you to the people in Pitivi, Mathieu Duponchelle, Alexandru “aleb” Băluț and Thibault Saunier for their help, advices and company through this way. Thank you very much specially for giving me this opportunity.

August 05, 2019

GSoC: Things I've been doing and what I learned until now

The second month of Google Summer of Code passed quickly. Last weeks I’ve been working on my markers code. My early implementation, while functional, needed a lot of cleaning, refactoring and refining to fit into Pitivi. Mathieu Duponchell and Alexandru Băluț have been guiding me through this process.

In GES I expanded the GESMarkerList with new signals, writed new tests and changed some unusual structures for others more usual in GES.

In Pitivi I added a new module with the markers logic, ‘markers.py’. Roughly speaking, now we have the class MarkersBox, which is a GTK.EventBox containing a GESMarkerList and a GTK.Layout to put on markers. The class Marker is also a GTK.EventBox, so we have a widget for every GESMarker, which allows to move, remove and select markers. The class MarkerPopover brings a popover menu to edit metadata in every marker. I also implemented undo and redo actions.

The process of rewriting a lot of my previous code has been hard and challenging. I knew that my original code wasn’t clear or optimized but I wasn’t sure how to exactly improve it. It implied to learn and apply some concepts which wasn’t clear to me. While hard work it felt as a rewarding and foundamental learning.

For future GSoC students I would like to recap some of the things and concepts I have learned or worked on with Pitivi. Maybe this would be useful for someone:

  • MVC:

Pitivi follows the Model-View-Controller pattern. In my early code I was binding together the View and Controller parts. For example, removing a marker: first I called the method to remove a marker and after that I had a line of code to redraw the removed marker. This would make impossible to use other controllers.

To change this I had to implement new signals in GESMarkerList, for removed and moved markers. Then in Pitivi I wrote handlers for these signals which updates the View. So, every time the Model is updated with a ‘remove marker’ it triggers a remote signal and the handler updates the view.

  • UNDO/REDO ACTIONS:

Undo/Redo actions are alternative controllers. Alternative controllers need the MVC. Without the signals that I wrote previously my undo/redo actions couldn’t work. The class MarkerObserver monitorize what happen with markers. It have handlers for every GESMarkerList signal. With every signal (add, remove and move) a new action is created and added to an action log. Every action have a method to implement undo and redo.

One complicate thing was that when a marker is removed and the user wants to undo that action, a new marker has to be created. This brings a new problem, if the user wants to undo to previous actions the reference to the original marker get lost, and previous actions in the stack don’t know about the last marker created to substitute the original marker.

Lucky me, Aleb guided me to the UndoableAutomaticObjectAction class who takes care of these situations, but it took me a while to discover how it works.

  • GTK:

Pitivi uses GTK, a toolkit for creating graphical user interfaces. And not everything is evident in GTK documentation.

To display markers we chose to use CSS styles. I wanted that the interface of the markers change while they are hovered or selected. But it was hard to make it work in EventBoxes. While in GTK.Button it works just right, it took me time to discover why that wasn’t working in our case. After some talk in the GTK channel we discovered that we needed to manually update the flags state in our widget:

def do_enter_notify_event(self, unused_event): self.set_state_flags(Gtk.StateFlags.PRELIGHT, clear=False)

def do_leave_notify_event(self, unused_event): self.unset_state_flags(Gtk.StateFlags.PRELIGHT)

Slightly out of context but this code made our CSS work

  • TIME AND COMMUNICATION:

These things took me more time that I would like. Being a beginner programmer isn’t easy, there are multiple factors which can block you. It’s hard to know if the thing that is blocking you is a trivial one or a hard one. Also, the desire of resolve all the problems by my own often result in a slower and inefficient pace. In my case all my problems got a new light when I talked with my menthors.

  • THE DEVIL IS IN THE DETAILS:

When I read quickly through the code I have a loose knowledge of what it does. Stackoverflow gives me the false impression that I understand everything in a hurry. Most of the time these approaches drive me to get stuck.

If I read carefully, line by line, taking my time to understand, to explain things to myself, to make questions, everything starts to make sense and flow. The same happens when I try to go for a big task without subtasking. And I noted that when I have a good understanding of the little parts is easier to refine the code later.

July 13, 2019

GSoC: First month working in Pitivi

_config.yml

Pitivi is a video editor, free and open source. Targeted at newcomers and professional users, it is minimalist and powerful. This summer I am fortunate to collaborate in Pitivi development through Google Summer of Code.

My goal is to implement an interval time system, with the support of Mathieu Duponchell, my menthor, and other members of the Pitivi community.

An interval time system is a common tool in many video editors. It will introduce new features in Pitivi. The user will be able to set up a range of time in the timeline editor, playback specific parts of the timeline, export the selected parts of the timeline, cut or copy clips inside the interval and zoom in/out the interval.

Mi proposal also includes the design of a marker system to store information at a certain time position.

_config.yml

Interestingly, we started working on the markers system. It was decided that it would be useful later in the interval implementation. To implement markers we have been working on GES, creating two new classes, GESMarkerContainer and GESMarker.

After define the API I started implementing it. At this stage it was incredible helpful to me the dedication of Mathieu orienting me along the process. GES could be “quite” complicate for newcomers like me but it also makes things more interesting! Thanks to my menthor I could focus, divide task into smaller and factible chunks, both in GES and Pitivi code.

_config.yml

My work until now can be summarized in these steps: implement something needed in the API, go to Pitivi and work there until I need something else from the API, then go back to the API…

After some redesings now we have a new row in the timeline, which allows us to insert markers, move and delete them, and edit their content, which for the moments is just a string. Of course they can be saved and recovered. UI is still provisional.

_config.yml

I am really enjoying the experience, my first time in open source. The code is huge, involves differents technologies and I have to work on different levels. But it feels challenging and the community is really supportive.

July 12, 2019

Google Summer of Code with Pitivi

GSoC with Pitivi

This summer I am working under the mentorship of Alexandru Băluț to improve the user experience of the Effects feature in Pitivi.

In the first phase of my project, I worked on redesigning Pitivi’s “Effect Library” to allow users to easily find, organise and utilize their desired effects.

Current Effect Library UI

My first assignment was to remove the ComboBox at the top and replace it with seperate Expanders for the various categories. In the process, we also decided to move away from showing Audio and Video effects separately, instead choosing to integrate “Audio” just as another category. This enabled us to present a hierarchical yet simple interface which also allowed the user to have multiple categories open at once.

The next order of business was to replace the tiny 4:3 thumbnails we have for the effects with larger and more expressive 16:9 ones (Thanks to Valentin Orient for contributing these beautiful new thumbnails!).

My final task for this phase was to add a “Favourites” feature which would allow the user to gather all the effects of their choice in a separate view for quick and easy access. For this, I added a button to the effects which enables the user to effortlessly check or change its “favorited” state.

New Effect Library UI

Concluding my work on the “Effect Library” and I will now be moving onwards to renovating the “Clip Tab” for the next phase.

If you wish to reach me, you can find me in #pitivi and #newcommers on GIMPNet as yat_irc.

June 27, 2019

Pitivi – Making a Nest

                              PiTiVi Logo.svg          Image result for google summer of code

Pitivi is an open source video editing software for Linux. It provides creatives with a simple and elegant interface to edit and bring their videos to realisation. As with every other great software, Pitivi’s development community is always striving to add newer and better features. This year I participated in the Google Summer of Code to add the ‘Nesting’ Feature to the platform. I am currently working on this with my mentor Thiblahute Saunier. In this blog I chart out our current progress and the future tasks at hand.

Nesting Clips:

With nesting users can combine a series of sequences into a master clip. This master clip can be edited on like a normal clip, while simultaneously providing users the ability to go into the master clip’s timeline and make changes. This will help them to organise the timeline, enable re-usability of sequences and provide a richer user experience. 

Nesting in Adobe Premiere Pro

(Here is a link to better understand Nesting: https://www.youtube.com/watch?v=A8Aw53JBLZY )

For the past weeks we have been working on the back-end, Gstreamer Editing Services(GES) to implement nesting of clips in a timeline. Earlier with ges-launch-1.0 we could create a timeline, load several clips to it with +clip , add effects to them +effect, set it’s property etc, now with ges-launch-1.0 .xges file can be used as source and nested timelines can be created.

(Here is a link to ges-launch-1.0 documentation: https://gstreamer.freedesktop.org/documentation/tools/ges-launch.html?gi-language=c#)

So while nesting in Pitivi, the idea is to create a new timeline, copy and paste the selected clips in this timeline, remove them from the main timeline and finally add the new timeline to the main timeline.

Now .xges file can be used as source and nested timelines can be created. So while nesting in Pitivi the idea is to create a new timeline, copy and paste the selected clips in this timeline, remove them from the main timeline and finally add the new timeline to the main timeline.

Testing:

gst-validate-launcher is used to create test suites to test the behavior of the created pipelines and test the user actions as described in the .scenario files.

(Here is the link to gst-validate-launcher documentation: https://gstreamer.freedesktop.org/documentation/gst-devtools/gst-validate-launcher.html?gi-language=c )

I have been busy implementing tests and writing scenarios for nesting. The test suite is working properly. For playback.nested tests, ges-launch-1.0 +clip is used to add the .xges file to the timeline instead of -l. Thanks to Thiblahute, most of the tests are passing successfully. So now ‘gst-validate-launcher ges’ generates and runs through the tests for Nesting.

The scenarios seek on nested timelines and check whether the outputted frame is correct. To be specific, they load a clip, serialize it in a .xges file, resulting in a nested timeline. It then loads the .xges file, seeks and checks the frame while moving them around in the layers and adding effects to the nested timeline. Basically, they emulate a user’s actions. Currently I am wrapping up a few scenarios.

The journey ahead:

The next part of the project will involve in the implementation and user interface of nesting in Pitivi. I had some ideas about the interface which I suggested in my proposal but we will be having rigorous discussions and decide the final interface.

My experience working in Pitivi:

In the past few weeks I’ve learnt and improved a lot. In the beginning I was a bit reserved and shy to tell my problems but after talking and getting to know my mentor, I think I’ve overcome that fear. The guidance of my mentor has been crucial in this journey. Until now he has done all of the heavy-lifting for the back-end all the while helping me to get up to speed. Hopefully now I will be able to take the reins and at the same time be able to learn more from him. I look forward to an amazing summer and the work we have in front of us.

May 10, 2019

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 http://flatpak.pitivi.org/pitivi.flatpakref

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!

April 22, 2019

GStreamer Editing Services OpenTimelineIO support

GStreamer Editing Services OpenTimelineIO support

OpenTimelineIO is an Open Source API and interchange format for editorial timeline information, it basically allows some form of interoperability between the different post production Video Editing tools. It is being developed by Pixar and several other studios are contributing to the project allowing it to evolve quickly.

We, at Igalia, recently landed support for the GStreamer Editing Services (GES) serialization format in OpenTimelineIO, making it possible to convert GES timelines to any format supported by the library. This is extremely useful to integrate GES into existing Post production workflow as it allows projects in any format supported by OpentTimelineIO to be used in the GStreamer Editing Services and vice versa.

On top of that we are building a GESFormatter that allows us to transparently handle any file format supported by OpenTimelineIO. In practice it will be possible to use cuts produced by other video editing tools in any project using GES, for instance Pitivi:

At Igalia we are aiming at making GStreamer ready to be used in existing Video post production pipelines and this work is one step in that direction. We are working on additional features in GES to fill the gaps toward that goal, for instance we are now implementing nested timeline support and framerate based timestamps in GES. Once we implement them, those features will enhance compatibility of Video Editing projects created from other NLE softwares through OpenTimelineIO. Stay tuned for more information!

April 16, 2019

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.

 

February 14, 2019

Polishing Pitivi's viewer

In the Pitivi video editor, the viewer is quite important, as it shows the video. Our viewer also shows a discreet frame around a clip selected in the timeline, making it easy to resize and position the video of the clip by dragging. Below is the story of the viewer updates in the past year.

Easy resizing

It was a bit cumbersome to have to drag both the left and bottom margins of the viewer container to resize it. We thought it would be easier to resize the viewer by simply dragging the bottom-left corner of its container. Harish Fulara made time at the end of his GSoC 2018 internship for this, after he finished his main task, and it works great! — 25609f3a

Are we 100% yet?

In Pitivi, the project resolution is conveniently set for new projects to match the first imported video file, and can be changed at any time. This project resolution applies to the video content, which at the end is resized when displayed by the viewer, depending on the size of the viewer. Of course resizing introduces artifacts, so we need a way to have the viewer display the video content at 100%, pixel for pixel.

Without introducing any new confusing UI, the simplest thing we could do was to show the resize status while the viewer is resized. Now the video dims when you resize the viewer, to see clearly the resize percent, and then is restored after a timeout with no change in size.

By connecting to the widget's width/height property-change signals, any size change is detected, irrespective of what caused it: the corner being dragged, or the window being maximized, etc. Thanks again to Harish and his GSoC for implementing this! —d91c1283

Sometimes it can be fiddly to set the viewer to 100%, since one pixel more and it's not 1:1 anymore. We thought about improving it by introducing snapping.

Snapping

Unfortunately, with snapping you won't be able to set your viewer size to 101%, but in return it's much easier to target 100%. Now the 100..105% range is down-snapped to 100%, to make it easy to display the video content without any resize artifacts. Harish researched how we can do this, but as school took him over, yours truly recently made time to finish the implementation. —371581a0



Once merged, looking back at my commit, like everybody does from time to time, ..closely, some code cleanup commits popped up, like mushrooms after rain. It's pretty cloudy in Zurich.

Better trimming preview

Normally the viewer is used to display the project video at the playhead position, but we also use it to display the start or end margins of a clip when it is being trimmed.

A long time ago it used to be the case that we had to limit the seek rate when trimming, for performance reasons, but now the seek is done async and our pipeline is smart enough to skip scheduled seeks if new ones come in. With the limit removed, now the trim preview is more precise and (up to 200ms) snappier. —42a7dc01

The code responsible for the switch between the project video widget and the clip video widget, when starting/finishing a trim operation, was very complex. It was checking in quite a few places, which one are we dealing with: the pipeline of the project or the pipeline of the trimmed clip. By keeping separate references to both, the logic is now much easier to read. As a bonus, now when the trim is finished, we directly display the project video, without having to wait for the pipeline state to go from NULL to PAUSED. —03e15b44

When a trim operation was being started, the trim preview was flickering. This was more noticeable when the end of the clip was trimmed. The first frame of the clip was being displayed for a split second before the first seek is done. Now we simply wait for the first seek to be performed before switching the viewer to show the trimming preview. —6d49ee54

It takes a very short time until the pipeline for a clip trim preview is ready, but why not have it instantly? At least when the user is focused on a handful of clips adjusting and trimming them, a cheap cache now does the job. —ec9ca33b

Contributing to Pitivi

Pitivi benefits from the GStreamer multimedia framework used on most Linux desktops and we contribute back in multiple ways. We could use some more hands on Pitivi. Contributions of any type would be greatly appreciated. Come chat with us. If you're a student, you can join us doing a GSoC internship this summer!

August 14, 2018

Google Summer of Code 2018 Final Report

August 12, 2018

[GSoC’18] Pitivi’s UI Polishing – Final Report

As part of Google Summer of Code 2018, I worked on the project Pitivi: UI Polishing. This is my final report to showcase the work that I have done during the program.

Work Done

I worked on the issue #1302 to integrate Pitivi’s welcome dialog box into its main window and display projects in a more informative, discoverable, and user friendly layout. This is how Pitivi greeted users before I started working on the issue:

Screenshot from 2018-08-11 13-59-26

My first task was to remove the welcome dialog from Pitivi and integrate a simple greeter perspective that displays the name of recent projects in a listbox with all the relevant buttons placed in the headerbar. This was a big task and took nearly 5 weeks to complete. The main challenge of this task was to understand the big codebase of main window and refactor it. The refactoration lead to the following architectural changes:

pitivi_architecture (2)

In the the new architecture, I have developed a perspective based system which allows easily adding more perspectives to Pitivi. Every class has single responsibility in the new architecture as opposed to everything being managed by main window in the previous architecture.

!33 is the merge request for this change and 330d62a4 is the committed code. This is how the greeter perspective looked like after this change:

pitivi_greeter_ad

I also did some code clean up to conclude my greeter perspective’s integration:

  • Remove unused “ignore_saved_changes” param from newBlankProject() function in project class – b2f19ea3
  • Make newly added shortcuts available when users upgrade Pitivi – 8b3a691a
  • Move dialog for locating missing asset to dialogs package – c08007a8
  • Remove directly called callback methods – 7a8d23ba
  • Remove project title functionality because we only care about project file name – 4ea9d89f

My next task was to display meta info regarding a project such as its directory and last updated timestamp in the greeter perspective. !43 is the merge request for this change and ff672460 is the committed code. This is how the greeter perspective looked like after this change:

aaa

My next task was to show a welcome message on greeter perspective when there are no recent projects. !44 is the merge request for this change and d9c8f6c8 is the committed code. This is how the empty (no recent projects) greeter screen looks like:

empty_greeter

Finally, I added the following to greeter perspective:

  1. “Search” feature for easy browsing of recent projects, and
  2. “Selection” feature for removing project(s) from recent projects list.

!46 is the merge request for search feature and c72ebce7 is the committed code. !48 is the merge request for selection feature and 809d7599 is the committed code.

searchSearch feature
removeSelection feature

After resolving issue #1302, I worked on the issue #1462 to integrate project thumbnails in greeter perspective. The main idea behind these thumbnails is to give the user a hint what a certain project is about. The main challange of this task was to come up with a simple and robust algorithm for thumbnail generation (link). More details about our project thumbnail generation approach can be found here.

!51 is the merge request for this change and a6511c1e is the committed code.

I also made the following optimizations to project thumbnails (!54):

  • Use assets thumbnails if no thumbnails are present in XDG cache – cb47d926
  • While opening greeter perspective, defer loading of project thumbnails until the main thread is idle – 37c973e1

So this is how the greeter perspective looks finally after all these changes:

Screenshot from 2018-07-21 00-29-40

After wrapping integration of project thumbnails, I added the following features to greeter perspective:

  • Right click on a recent project to select it and start selection mode – !67 is the merge request and 6db06472 is the committed code
  • Drag & drop a project file from Nautilus onto greeter to open it – !68 is the merge request and 817d885a is the committed  code

Next, I worked on the issue #1816 to allow video viewer resizing.

The first task was to integrate a marker on the bottom left corner of the viewer container to allow for easy resizing of the viewer. !60 is the merge request for this change and 25609f3a is the committed code.

resize1Viewer resizing using corner marker

Work in Progress…

Two more tasks are left under issue #1816:

  1. Displaying resize status (in %) over slightly dimmed video, and
  2. Snapping of viewer to 100% and 50% if the current resize status is between [100%, 100% + Δ ] and [50%, 50% + Δ ] respectively.

I have submitted a merge request !70 for review for both these tasks.

resize2Displaying resize status over dimmed video

Final Words

I would like to thank my mentor Alexandru Băluț (aleb) for his help and guidance throughout this project. I would also like to thank all other members of GNOME community who helped me along the way. This turned out to be an amazing summer for me with lots of learning and fun. I will continue to contribute to Pitivi as I feel like this is just the beginning of many exciting things yet to be done in Pitivi to make it the best video editing application.

Until next time 🙂

August 09, 2018

Pitivi's Planned Proxying Process

With the addition of scaled proxies into the mix, the current UI needed be altered to allow for simple and convenient use of both Optimized Media and Scaled Proxies

  • Proxying from the Media Library

    Media Library

    Here, simply adding the option to create scaled proxies alongside the newly renamed “Use Optimized Proxy” option provided a easy and elegant UX.

    Media Library Icons

    And to distinctly display scaled assets, a new brightly colored lightning icon was introduced to be shown on suitable thumbnails in the Media Library.

  • Automatic Proxying during Import

    Redesigned Import Dialog

    The import dialog already looked quite bloated with the old proxy settings so it was decided to redesign the dialog to make it look lean and clean.

    The settings for optimized media were compressed into a single line with a checkbox providing easy enable-disable functionality.

    For scaled proxies, it was decided to use the already present scaled proxy resolution as the cut-off resolution for automatic scaling. Care was taken to let the user to see and modify this resolution quickly and easily. This allows them to specify a single resolution and be confident that only the assets that need scaling will be transcoded.

August 08, 2018

Pitivi's Present Proxying Practises

Currently, there are two ways to create proxies in Pitivi

  • Using the Import Dialog during ingestion of media

    Old Import Dialog

    This method is automatic in nature and enables the user to just import all the media he/she needs and let Pitivi chose when to use proxies.

    Pitivi will automagically replace poorly supported media with Optimized Media during the import itself.

    While this works seamlessly for optimized media, the situation is slightly complicated for scaled proxies. Not only can it be difficult to determine which assets to scale, we also want to know what resolution to scale them to.

    Plus, letting Pitivi automagically scale down media to a noticeably lower resolution might backfire if the user isn’t privy to what is happening behind the scenes.

  • Using the Media Library during editing

    Old Media Library

    This approach involves much less “magic” and is bit more WYSIWYG in its character.

    In the Media Library the user can start proxying assets with just two clicks and see which assets are proxied or being proxied in a single glance. This is useful if the user wishes to modify the state of assets while editing.

    It’s much easier to fit scaled proxies here as long as we take care to make it obvious which assets are proxied and with what type of proxies.

August 07, 2018

Pitivi's Proxy Preparation Procedure

Pitivi Logo

Internally, most of the code for handling proxies resides in proxy.py which exposes the proxy_manager class to create and monitor proxy assets.

To create a proxy, we call add_job function in proxy_manager which takes the GES.Asset that we wish to proxy as its argument, performs some checks and passes it on to another function.

This function is now responsible for getting the suitable EncodingProfile and starting off a GstTranscoder on the asset with this profile as its target format.

The transcoder runs asynchronously, reporting progress periodically which is used to update the UI in the Media Library.

When the transcoder finishes, we GES.request_async the resulting proxy file and set it as the proxy on the original asset.

The modifications required for the generation of scaled proxies are fairly straightforward, just set_restriction on the EncodingProfile telling it the height and width that we wish to scale the asset to and let GstTranscoder work its wonders.

The complications lie mostly in adapting the current framework that is used for initiating proxy creation, managing proxies during their lifecycle and handling of edge cases like poorly supported the formats or the changing of the target resolution for scaled proxies mid-way through.

August 06, 2018

Google Summer of Code with GNOME

GSoC with GNOME

This summer I , under the mentorship of Thibault Saunier, will be working on adding scaled proxies to Pitivi. While Pitivi already provides its users the option to use Optimized Media (aka HQ Proxies) for problematic file formats, having scaled proxies would allow them to transcode their high resolution video assets to a more manageable resolution at the time of editing which would make both editing and previewing much quicker.

Some of the other editors allow users to attach externally transcoded assets as proxies, this approach is flexible but not very user friendly. Pitivi, a bit like Final Cut Pro, provides a single unified experience where user can create and manage proxies right there in the application itself.

My project aims to integrate scaled proxies within Pitivi’s current framework for creating proxies and making sure that they are adaptable yet remain easy to use. You can find in #pitivi and #newcommers on GIMPNet as yat_irc or look at (most of) my work on this issue.

July 31, 2018

WebKitGTK and WPE gain WebRTC support back!

WebRTC is a w3c draft protocol that “enables rich, high-quality RTP applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols”. The protocol is mainly used to provide video conferencing systems from within web browsers.

https://appr.tc running in WebKitGTKhttps://appr.tc running in WebKitGTK

A brief history

At the very beginning of the WebRTC protocol, before 2013, Google was still using WebKit in chrome and they started to implement support using LibWebRTC but when they started the blink fork the implementation stopped in WebKit.

Around 2015/2016 Ericsson and Igalia (later sponsored by Metrological) implemented WebRTC support into WebKit, but instead of using LibWebRTC from google, OpenWebRTC was used. This had the advantage of being implemented on top of the GStreamer framework which happens to be used for the Multimedia processing inside WebKitGTK and WebKitWPE. At that point in time, the standardization of the WebRTC protocol was still moving fast, mostly pushed by Google itself, and it was hard to be interoperable with the rest of the world. Despite of that, the WebKit/GTK/WPE WebRTC implementation started to be usable with website like appr.tc at the end of 2016.

Meanwhile, in late 2016, Apple decided to implement WebRTC support on top of google LibWebRTC in their ports of WebKit which led to WebRTC support in WebKit announcement in June 2017.

Later in 2017 the OpenWebRTC project lost momentum and as it was considered unmaintained, we, at Igalia, decided to use LibWebRTC for WebKitGTK and WebKitWPE too. At that point, the OpenWebRTC backend was completely removed.

GStreamer/LibWebRTC implementation

Given that Apple had implemented a LibWebRTC based backend in WebKit, and because this library is being used by the two main web browsers (Chrome and Firefox), we decided to reuse Apple’s work to implement support in our ports based on LibWebRTC at the end of 2017. A that point, the two main APIs required to allow video conferencing with WebRTC needed to be implemented:

  • MediaDevices.GetUserMedia and MediaStream: Allows to retrieve Audio and Video streams from the user Cameras and Microphones (potentially more than that but those are the main use cases we cared about).
  • RTCPeerConnection: Represents a WebRTC connection between the local computer and a remote peer.

As WeKit/GTK/WPE heavily relies on GStreamer for the multimedia processing, and given its flexibility, we made sure that our implementation of those APIs leverage the power of the framework and the existing integration of GStreamer in our WebKit ports.

Note that the whole implementation is reusing (after refactoring) big parts of the infrastructure introduced during the previously described history of WebRTC support in WebKit.

GetUserMedia/MediaStream

To implement that part of the API the following main components were developed:

  • RealtimeMediaSourceCenterLibWebRTC: Main entry point for our GStreamer based LibWebRTC backend.
  • GStreamerCaptureDeviceManager: A class to list and manage local Video/Audio devices using the GstDeviceMonitor API.
  • GStreamerCaptureDevice: Implementation of WebKit abstraction for capture devices, basically wrapping GstDevices.
  • GStreamerMediaStreamSource: A GStreamer Source element which wraps WebKit abstraction of MediaStreams to be used directly in a playbin3 pipeline (through a custom mediastream:// protocol). This implementation leverages latest GstStream APIs so it is already one foot into the future.

The main commit can be found here

RTCPeerConnection

Enabling the PeerConnection API meant bridging previously implemented APIs and the LibWebRTC backend developed by Apple:

  • RealtimeOutgoing/Video/Audio/SourceLibWebRTC: Passing local stream (basically from microphone or camera) to LibWebRTC to be sent to the peer.
  • RealtimeIncoming/Video/Audio/SourceLibWebRTC: Passing remote stream (from a remote peer) to the MediaStream object and in turn to the GStreamerMediaStreamSource element.

On top of that and to leverage GStreamer Memory management and negotiation capabilities we implemented encoders and decoder for LibWebRTC (namely GStreamerVideoEncoder and GStreamerVideoDecoders). This brings us a huge number of Hardware accelerated encoders and decoders implementations, especially on embedded devices, which is a big advantage in particular for WPE which is tuned for those platforms.

The main commit can be found here

WebKitWebRTC dataflow diagram

Conclusion

While we were able to make GStreamer and LibWebRTC work well together in that implementation, using the new GstWebRTC component (that is now in upstream GStreamer) as a WebRTC backend would be cleaner. Many pieces of the current implementation could be reused and it would allow us to have a simpler infrastructure and avoid having several RTP stack in the WebKitGTK and WebKitWPE ports.

Most of the required APIs and features have been implemented, but a few are still under development (namely MediaDevices.enumerateDevices, canvas captureStream and WebAudio and MediaStream bridging) meaning that many Web applications using WebRTC already work, but some don’t yet, we are working on those!

A big thanks to my employer Igalia and Metrological for sponsoring our work on that!

July 24, 2018

[GSoC 2018] Welcome Window Integration in Pitivi – Conclusion

In my last post (link), I talked about integrating “Search” and “Remove” feature in Pitivi’s welcome window. Search feature allowed for easy browsing of recent projects and remove feature allowed removing project(s) from recent projects list.

In this post, I want to introduce “Project Thumbnails”. I have successfully integrated project thumbnails in recent projects list. This is the last task under issue 1302.

The main idea behind thumbnails is to give the user a hint what a certain project is about. This can be seen as information in addition to project name and uri which helps to identify the desired project faster and more easily.

Screenshot from 2018-07-20 23-01-52Project thumbnails integrated in recent projects list

We display our project thumbnails in a dark grayish container of size 96×54 (16:9). We preserve the aspect ratio of our project thumbnails while displaying them in the container, for example, aspect ratio of thumbnail of project “demo3” in the above screenshot is 21:9 while projects “demo7” and “demo1” have 16:9 aspect ratio thumbnails. If a project has no thumbnail, such as an empty project, we show “video-x-generic” theme icon as project thumbnail, for example, project “demo4” in the above screenshot.

We create a thumbnail for a project if and only if:

  • the project doesn’t have a thumbnail, or
  • user imported/deleted asset(s) while working on the project.

Our project thumbnail generation approach is as follows:

  1. We go through all the assets in the project and fetch their thumbnails from the XDG cache.
  2. Out of all the fetched thumbnails, we pick the one with maximum file size as our project thumbnail (Why?).
  3. If we are not able to get any thumbnail from the XDG cache, we pick the preview thumbnail of the first asset that has a thumbnail cache** as our project thumbnail.

** This is the cache maintained by Pitivi for the assets imported in a project. This is different from XDG cache. XDG cache is a system wide cache for thumbnails.

So, finally after 10 weeks, I conclude the issue 1302. To give a brief idea of what I did in these 10 weeks, this is how welcome dialog in Pitivi looked 10 weeks back…

Pitivi's Current Welcome Dialog

And this is how it looks now…

Screenshot from 2018-07-21 00-29-40

I would also like to express my gratitude to my mentor Alexandru Băluț (aleb) for helping and guiding me throughout these 10 weeks.

Next, I will be working on the issue 1816. My aim is to complete it in the next 2 weeks.

I will keep posting my progress on this blog. Until next time.

Stay tuned 🙂

Writing a freesound plugin for Pitivi

I always say that my first geeky passion is computer programming. But that is a passion I developed about 8 years ago. Another geeky passion I have recently developed has been security analysis. Because of this reason I started a Youtube channel the previous year called “Inversor Moderno” (“Modern investor” in English). Besides the fact that I prefer to follow the fundamental analysis and to be more specific the “value investing” philosophy, I started the channel with the purpose of leaning and teaching more about investments and specifically about quantitative trading. However, it has been a long time since the last time I uploaded a video.

Inversor moderno intro

The intro of my videos was made using Blender and Pitivi. The bag of money was made in Blender and the sound of the Wall Street bell was added using Pitivi. All the rest of each video in my channel are made using Pitivi. I consider that the best ideas you may have come up when you really start to eat your own dog food. When I was animating the intro, I remembered that when I started trading, the platform I used notified me with a Wall Street bell sound when a position touched “take profit” or “stop loss”. So I wanted to add a sound like this one to my intro. Then I thought: “It would be nice if Pitivi had a sound library”.

Flashback: I remember I had an introductory course in the university in which students had as an assignment task to develop a video game. Nobody knew how to develop a video game, but the idea was also to research. By that time, I knew something about Blender and the BGE and I could convince to my friends to use Blender. We modeled the university in Blender and then put a human in there with Makehuman. But our game needed sounds. Searching for Creative Commons sounds, I found the Freesound database.

preview

Luckily, not only has an API to access their sound database, but it also has a [Python module](https://github.com/MTG/freesound-python). So I decided to write a plugin that allows to query for some sounds from Pitivi and importing them to the Pitivi Media Library. I made the first step the previous year, but I didn't continue it. This last week, I decided to continue this mini-project. The plugin is working now, but there are some things to complete and a lot more to review. However, you can see a preview here.

preview

I need suggestions about design. I am still not sure if I should use a GtkListBox or if a GtkTreeView would look better. Also I don’t know what message should be shown when no result is found after searching and also what message to show when the Freesound library window is open for the first time.

You can try this feature in my branch (yes, it needs to be rebased).

July 14, 2018

[GSoC 2018] Welcome Window Integration in Pitivi – Part 4

In my last post (link), I talked about:

  1. Changing the layout of recent projects items to display meta info regarding a project such as its directory and last updated timestamp, and
  2. Displaying greeter message when there are no recent projects.

In this post, I want to introduce the two new features that I have added to the new welcome window in Pitivi:

  1. “Search” feature for easy browsing of recent projects (box marked as “1” in the screenshot below), and
  2. “Remove” feature to allow removing project(s) from recent projects list (box marked as “2” in the screenshot below).

sear

“Search” feature…

Search feature is meant to allow users to easily browse throught recent projects list to quickly get to the project they want to work on. This feature can be pretty handy if there are lots of recent projects.

I have implemented it using Gtk.SearchEntry and it is focussed by default to allow users to quickly search for a project as soon as the welcome window appears.

Screenshot from 2018-07-14 23-53-19Recent projects found for search query “demo1”
Screenshot from 2018-07-14 23-55-01No recent project found for search query “demo12”

“Remove” feature…

Remove feature is meant to remove unwanted/unused project(s) from recent projects list. The removed project(s) are not deleted from the disk. One use case for this feature can be to unclutter the recent projects list after we have finished working on a project and we no longer need it.

Screenshot from 2018-07-15 00-06-45Remove project(s) screen
Screenshot from 2018-07-15 00-09-02Selected “demo4” project for removal
Screenshot from 2018-07-15 00-10-18“demo4” project removed from recent projects list

The next and the last task under “Welcome Window Integration in Pitivi” as per my GSoC project is to integrate project thumbnails in recent projects list. I am currently working on this task and hope to finish it by next week.

I will keep posting my progress on this blog. Until next time.

Stay tuned 🙂

July 12, 2018

[GSoC 2018] Welcome Window Integration in Pitivi – Part 3

In my last post (link), I talked about Pitivi finally getting a Welcome window. In this window, the layout of the recent projects list was pretty basic – we were only showing the name of the projects.

pitivi_greeter_adWelcome window – “Recent Projects” list is only showing name of projects

The next two tasks on my ToDo list were –

  1. Displaying meta info regarding a project, such as its directory and last updated timestamp, and
  2. Greeter message on Welcome window when there are no recent projects.

I have successfully completed these two tasks. The layout of recent projects list now shows project name, project uri, and project’s last updation timestamp.

greeter_newNew layout of recent projects list

Note: If the project is inside user’s home directory, we replace the home directory path with (tilde).  Also, the “Updated” info might not be accurate everytime as it is not displaying project’s last updation timestamp in very specific manner (like 30 mins ago, 2 days ago, etc.) but in a vague manner (like Just now, Yesterday, etc.). The idea is to present this info in a nice human readable format and not care much about the accuracy of the timestamp as it doesn’t matter too much for a video editing app. Also, there are other GNOME apps like Builder who display updation timestamp in exact same manner.

This is how the empty (no recent projects) greeter screen looks like –

empty_greeter

For now we have kept this screen very simple as it is more like a one time welcome screen and we don’t want to put a lot of effort into it as we have other important tasks at hand. Almost all the time users will be dealing with the screen displaying recent projects.

The next two tasks on my ToDo list are:

  1. Adding search functionality for easy browsing of projects.
  2. Allowing removing items from “Recent Projects” list.

I will keep posting my progress on this blog. Until next time.

Stay tuned 🙂

June 22, 2018

Behind the GESSourceClip rate

Initial Approach

GES has an effects infrastructure for adding and managing GStreamer elements. Since the rate property uses videorate and pitch elements to work, the idea was to use this existing infrastructure but to the hide the effects from the user as they are required only internally.

Step 1: Use effects

All media elements are truly set on a clip only when it is added to a layer, this involves the construction of GESAudioSource and/or GESVideoSource of the clip. An effect can be added only after these sources have been added to the clip. As a result, the rate property was configured to add pitch and/or videorate as effects only after the sources were added.

Step 2: Hide the effects

To hide the effects from the user - accommodate the hidden effects in GESClip by mimicing the behaviour of a normal effect and maintain a reference to the ‘hidden’ rate changing effects to not display them as top effects.

A GESClip is a subclass of GESContainer - which gives it the ability to hold the source track elements and the effects. Many operations in GES call the GES_CONTAINER_CHILDREN (clip) method when required to retrieve and make changes to the children of a clip - effects/sources contained in the clip. Since the rate changing effects were not truly hidden, they are contained in the clip and hence showed up as the container’s children.

Step 3: Start from scratch

Although the above approach of maintaining hidden effects works to hide them from the user, to hide and make GES sometimes ignore and sometimes utilise the effect API was not only difficult but required making a lot of ugly changes to many parts of GES. It became obvious that a rework of the way things worked was required when running tests on the branch resulted in most of the existing tests failing.

Current Implementation

Mathieu suggested that instead of using the effect API, we should dig a little deeper and add the videorate and pitch elements to the sources of the clip ourself. This genius and simple solution eliminated many of the problems faced in the initial approach.

pitch is simply added to the audiosrcbin- a GstBin of GESAudioSource, while videorate was already in place in a GESVideoSource to adjust frames, as a result, rate is now added as a child property of the audio and video source in GES. The parent GESSource handles creating, linking and managing the audiosrcbin and videosrcbin. Rate property added to GESSourceClip - base class for sources of a GESLayer, changes the rate child property of its sources to function.

The pitch element being from the gst-plugins-bad didn’t behave so well and required some fixes for bug 796603 by Matheiu and a followup fix for bug 796613 by myself after which all existing tests of GES passed! (hurray)

While pushing new tests, I realised that since we no longer rely on the effect API, the rate property had to be serialised and deserialised by adding to the xges xml formatter.

Same functionality with ges-launch holds, simply adding rate to command changes speed of a clip.

ges-launch-1.0 +clip ~/path/to/video.mp4 inpoint=10 duration=20 rate=2.0

The above command plays the 20 seconds of the input video from the 10 second mark at a rate of 2.0, that is, for 10 seconds.

The project can saved and loaded back-in using the following commands,

ges-launch-1.0 +clip ~/path/to/video.mp4 inpoint=10 duration=20 rate=2.0 --save project.xges

ges-launch-1.0 --load project.xges

The primary focus of work has been on the getting the GES implementation right. I’m yet to try out a few suggestions I got from GNOME design on the Pitivi UI side of things.

This has been the story so far. You can find my work here and follow issue 2202 for updates. Until next time.

June 21, 2018

[GSoC 2018] Welcome Window Integration in Pitivi – Part 2

In my last post (link), I gave an overview of Welcome window integration in Pitivi. I started working on this task from the first coding day of Google Summer of Code 2018, i.e. May 14, 2018 and after one amazing month of coding it finally got merged (commit) on June 19, 2018. Apparently it was a large change consisting of 702 additions and 329 deletions (link) involving 75 code-review discussions and 29 versions. A special thanks to my mentor aleb for giving constructive reviews on my code.

So, finally Pitivi has a Welcome Window!!! and this is how it looks like:

pitivi_greeter_alWelcome window – Adwaita light theme
pitivi_greeter_adWelcome window – Adwaita dark theme

There are two major changes in the Editor window:

1. We have added a “Close Project” button in the header bar of Editor window that closes the current project and opens Welcome window.

editor-headerbar“Close Project” button (highlighted in right)

2. We have removed “New Project” and “Open Project” options from the menu because these options are already provided in the Welcome window’s headerbar and it can get confusing for the user to have these in multiple places.

In the coming weeks, I will do more additions to the Welcome window such as:

1. Custom project view – displaying meta info regarding a project, such as its directory and last accessed timestamp.

custom_viewInitial design of custom project view

2. Greeter message on Welcome window when user opens Pitivi for the first time or when there are no recent projects.

3. Integrating project thumbnail into project’s custom view.

4. Adding search functionality for easy browsing of projects.

5. Allowing removing items from “Recent Projects” list.

I believe there are more exciting things to come in the upcoming weeks. I will keep posting my progress on this blog. Until next time.

Stay tuned 🙂

June 02, 2018

[GSoC 2018] Welcome Window Integration in Pitivi – Part 1

I will be working on Pitivi as my Google Summer of Code 2018 project under GNOME. One of the major task in my project is to integrate the current Welcome dialog box of Pitivi into it’s main window and display projects in a more informative, discoverable, and user friendly layout.

Currently when Pitivi starts, a Welcome dialog appears that displays the recent projects and some buttons for creating a new project, browsing projects, etc. This dialog box needs to be integrated into the main window.

Pitivi's Current Welcome DialogPitivi’s current welcome dialog

Some GNOME apps that already have their Welcome screen integrated into their main window are Builder, Boxes, Notes, ToDo, etc.

builderIntegrated welcome window in GNOME Builder app
ToDoIntegrated welcome window in GNOME ToDo app

The integration of Welcome dialog into Pitivi’s main window will provide us with more space that will be used for –

  • displaying relevant meta information regarding a project like its directory, last access timestamp, thumbnail, etc. in a nice custom layout rather than just displaying the title of the project (which we currently do in Pitivi’s Welcome dialog)
  • displaying projects categorically as “Starred” and “Recent”
  • providing a search interface to allow for easy browsing of projects
  • better positioning of the buttons based on their actions. Rather than stacking all
    the buttons vertically (which we currently do in Pitivi’s Welcome dialog), we will
    place Important buttons like  “New Project”, “Open Project”, etc. in the Header Bar, and Other buttons like “Help”, “Keyboard Shortcuts”, etc. inside a menu in the Header Bar

As of now, I have integrated the welcome dialog into Pitivi’s main window. Now, we have two main screens in Pitivi – Greeter Perspective (the welcome screen) and Editor Perspective (the video editing screen). The main window manages these perspectives and handles the switch between them.

pitivi_new_1Integrated welcome/greeter window in Pitivi. Notice that the important action buttons like “New” and “Open” are shown prominently in the header bar.
pitivi_new_2Integrated welcome/greeter window in Pitivi. Notice that other (not so important) action buttons like “Keyboard Shortcuts”, “User Manual”, etc. are shown inside a menu in the header bar.

Currently, I have a merge request pending for this change !33. I will keep posting my progress on this blog and on the issue 1302. Until next time.

Stay tuned 🙂

Bringing slow motion to Pitivi

GSoC again :)

Last year, I worked on the project ‘Pitivi: Color correction interface using three chromatic wheels’ as part of my Google Summer of Code. This year again, I’m working on Pitivi under the GNOME organisation. Mathieu Duponchellle and Thibault Saunier are mentoring my project this time.

For the past couple of weeks, I’ve been hacking on GStreamer Editing Services (GES), Pitivi’s backend, to add the ‘rate’ property to a clip. This is the first step towards my project ‘Slow-motion Video’ which has two objectives:

  • Add the clip speed feature to Pitivi
  • Allow parts of a single clip to have variable speeds.

A closer look

The newly introduced ‘rate’ property to a clip uses two GStreamer effects - videorate and pitch to modify the rate of video and audio respectively. GES already facilitates adding and maintaining effects. These effects while relying upon the existing framework to work are kept hidden from the user as internal effects.

A GESClip is a subclass of GESTimelineElement, it therefore has the following relevant properties:

GstClockTime start position (in time) of the object
GstClockTime inpoint position in the media from which the object should be used
GstClockTime duration duration of the object to be used
GstClockTime maxduration The maximum duration the object can have

On changing the rate, the duration and max-duration change as a result.

  duration = input_duration/rate
  maxduration = (asset_duration - inpoint)/rate + inpoint

where, input_duration is the duration of the asset being used and asset_duration is the entire duration of the asset.

After having made the above change to GES, I made a simple UI in Pitivi to test out the rate feature. Speed property is now part of clip properties. Here’s what it looks like

Yuna Proj

I also enabled the ‘rate’ property of GESClip to work with ges-launch - a command line tool which can be used to create multimedia timeline and render/play it.

ges-launch-1.0 +clip ~/path/to/video.mp4 inpoint=10 
duration=20 rate=2.0

The above command plays the 20 seconds of the input video from the 10 second mark at a rate of 2.0, that is, for 10 seconds.

The complex part is to ensure that the entire infrastructure remains stable on this addition and this is what I am currently up to. I’m constantly pushing fixes to ensure that all existing features and operations in GES and Pitivi work with the rate property. Hopefully, by the next time I blog I can upload a clean demo video showcasing the rate feature in Pitivi :)

You can find my work on the issue 2202. Feel free to ping me on #pitivi channel on freenode. Until next time.

April 27, 2018

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.

video_settingsThe aspect ratio settings removed from the project settings dialog

April 12, 2018

How to use the x264 encoding presets when rendering an XGES project

x264 has a few generic encoding presets you can use when rendering. You can see the list of presets and exactly what encoding options they specify by running x264 --fullhelp. You'll most probably notice the following presets: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow. Ideally you'd always use veryslow when rendering, but you can't always wait for it to finish, so you go for faster ones. The ffmpeg wiki summarizes the difference between these presets:
veryslow helps about 3% compared to the slowerpreset, slower helps about 5% compared to the slow preset, and
slow helps about 5-10% compared to the medium preset.
To be able to use for example slow with ges-launch-1.0, you need to create a GStreamer preset. Add the following section to ~/.local/share/gstreamer-1.0/presets/GstX264Enc.prs
[slow12mbps]
speed-preset=slow
bitrate=12288
You need to specify a bitrate in kbits per second because the default value of 2048 kbits per second might not be what you want. I picked 12288 because it's what YT recommends for 1920x1080p50. See the documentation for the x264enc plugin to see all the options you can specify in the preset.

You might also be interested in specifying a tune:
tune=stillimage
 or a psy-tune:
psy-tune=film
Other tune values are: film, animation, grain, psnr, ssim. For the list of available tune values see the plugin source code.

To use the new preset, run:
$ ges-launch-1.0 -l pitivi-project.xges -o out.mp4 -f "video/quicktime,variant=iso:video/x-raw,width=1920,height=1080->video/x-h264+slow12mbps:audio/mpeg,mpegversion=1,layer=3"
The -f parameter accepts a serialized encoding profile.

Pitivi moves from Bugzilla to Phabricator

Using Bugzilla to manage Pitivi was a bit painful and we were looking for a replacement. Many projects seemed to switch to Phabricator lately, which looked like a very good platform for managing projects. We experimented migrating Bugzilla bugs to Phabricator, and we are pretty content with the result. The UI is nicer, we have a better search function, and the Git integration (with the code review component) works great.

We decided to make the switch official, so we updated the documentation on the wiki and website to link to Phabricator, closed the Pitivi Bugzilla “product” and closed the remaining bugs in Bugzilla with a custom made script. The script also linked each bug to the proper task in Phabricator.

For those new to Phabricator, remember that instead of creating a “bug” you create a “task”.

The War Against Deadlocks, part 2: GNonLin’s reincarnation (the other thousand Deadlocks)



GNonLin has served our cause well for a number of years, but was left with indelible marks from the Old World. We grew increasingly worried with GNonLin’s common affiliation with Deadlocks, to the point where it was known as “the Baron of Deadlocks” by our battalion. We tried correcting it, tried reasoning with it, but alas—we only got “not-negotiated” caps errors.


A swift operation took place. The baron was captured and we applied a mix of heavy persuasion and alchemy, until it renounced its questionable affiliations and was reborn. The rise of the Non Linear Engine (“NLE”) plugin brought much joy in the county. Users are no longer harassed by renegade Deadlocks as they peacefully seek along their timelines. The Deadlocks may still try to haunt us, but it’s a whole New World, in which old tricks won’t affect us anymore.


CaptureMission.jpg
Pictured: "The Capture of the Baron"


In the words of the Maintainers:


We reused parts of the videomixer plugin to create the compositor plugin, which, in comparison, is thread safe. The new compositor plugin is already used by quite a few multimedia apps. In this process we created a new base class, which helped rewriting the audiomixer plugin to fix it and make it thread safe. This allowed us to switch from using adder to using audiomixer.

As you might know, the GStreamer plugins are used for creating pipelines, for example: (video1 * effect1) + video2 = x. The compositor plugin implements the + in this equation. A pipeline is used by NLE to play a video project. NleComposition translates a project’s timeline into a GStreamer pipeline dynamically, depending on the current position:




Recently we finished the replacement of GNonLin with Non Linear Engine. This means the composition uses a master thread for setting up the pipeline, whereas before the old composition used to unlink/relink new pipelines from both the streaming thread and from the seeking thread and this was causing Deadlocks (“the other thousand”). Whatsmore, we previously had to have all the elements in the entire timeline available in the composition in the PAUSED state, which meant there were many—so many!—useless threads, created and waiting like sitting ducks; whereas elements are now created only when the pipeline needs them, and they are kept in the READY state until they are actually used by the pipeline.


Long live Non Linear Engine!

Setting up Supybot with the Bugzilla plugin

Supybot is an IRC bot, an application which can connect to a specific IRC channel and do stuff there. For example, with the Bugzilla plugin, Supybot can report on the channel whenever a new bug is filed, or if somebody mentions "bug 1234" in the conversation, it will print details about bug 1234.

Install supybot

First, you have to install Supybot. If you are using Arch Linux, get supybot from AUR, otherwise read the INSTALL file.

Create a supybot user on your system, or on a virtual machine where you want to run the bot.

groupadd --system supybot
useradd -m --system -g supybot supybot

Install the supybot Bugzilla plugin

If you want your bot to announce when new bugs are created, you need to set up an email account, register it on bugzilla and set it up so it gets mails when bugs for your project are created. For this go to Bugzilla -> Preferences -> Email Preferences and read the User Watching section!

Once you have the email account receiving emails from bugzilla, setup getmail on your machine so it downloads the messages from the email account to /var/mail/supybot.

touch /var/mail/supybot
chown supybot.supybot /var/mail/supybot
chmod g+w /var/mail/supybot
chmod o-rwx /var/mail/supybot
chown supybot.supybot /var/mail/supybot

Set the getmail job to download the messages using POP and to delete them from the server after retrieving them.

[destination]
type = Mboxrd
path = /var/mail/supybot

[options]
verbose = 2
message_log = ~/.getmail/gmail.log

Now add yourself to the supybot group (so your getmail cronjob can write the bugzilla emails to /var/mail/supybot). For this to take effect the best option is to re-login!
usermod -a -G supybot YOUR_USERNAME

Add a crontab to your account (not supybot) to fetch the bugzilla mail every minute.

* * * * * getmail -d -q -r /path/to/your/getmail/config/file

Setup your bot

Next you have to create a config, and here it gets even more tricky. Unfortunately, most of the Supybot documentation is gone because the supybot.com website is dead and only redirects to the sourceforge page of the project, where Supybot can be downloaded. You have to create a config using supybot-wizard:

mkdir /home/supybot/pitivi
cd /home/supybot/pitivi
# I suggest to act as an "advanced user" when the wizard asks you
# about what kind of user you are!
supybot-wizard
[...]
# Now see the conf file it created, feel free to rename it to bot.conf. ;)
ls -l *.conf


Copy the Supybot Bugzilla plugin to your setup. Unfortunately the original repository is broken, but you can get it from my Supybot Bugzilla repository.

cd /home/supybot/pitivi
mkdir plugins
cd plugins
bzr co bzr://bzr.everythingsolved.com/supybot/Bugzilla # Broken
git clone https://github.com/aleb/supybot-bugzilla.git Bugzilla


Copy the bugzilla section from this sample config file to your bot.conf file. Or copy it from the pitivibot's bot.conf file below.

###
# Determines the bot's default nick.
#
# Default value: supybot
###
supybot.nick: pitivibot

###
# Determines what alternative nicks will be used if the primary nick
# (supybot.nick) isn't available. A %s in this nick is replaced by the
# value of supybot.nick when used. If no alternates are given, or if all
# are used, the supybot.nick will be perturbed appropriately until an
# unused nick is found.
#
# Default value: %s` %s_
###
supybot.nick.alternates: %s` %s_

###
# Determines the bot's ident string, if the server doesn't provide one
# by default.
#
# Default value: supybot
###
supybot.ident: supybot

###
# Determines the user the bot sends to the server. A standard user using
# the current version of the bot will be generated if this is left
# empty.
#
# Default value:
###
supybot.user: pitivibot

###
# Determines what networks the bot will connect to.
#
# Default value:
###
supybot.networks: freenode

###
# Determines what password will be used on freenode. Yes, we know that
# technically passwords are server-specific and not network-specific,
# but this is the best we can do right now.
#
# Default value:
###
supybot.networks.freenode.password:

###
# Determines what servers the bot will connect to for freenode. Each
# will be tried in order, wrapping back to the first when the cycle is
# completed.
#
# Default value:
###
supybot.networks.freenode.servers: chat.eu.freenode.net

###
# Determines what channels the bot will join only on freenode.
#
# Default value:
###
supybot.networks.freenode.channels: #pitivi

###
# Determines what key (if any) will be used to join the channel.
#
# Default value:
###
supybot.networks.freenode.channels.key:

###
# Determines whether the bot will attempt to connect with SSL sockets to
# freenode.
#
# Default value: False
###
supybot.networks.freenode.ssl: False

###
# Determines how timestamps printed for human reading should be
# formatted. Refer to the Python documentation for the time module to
# see valid formatting characters for time formats.
#
# Default value: %I:%M %p, %B %d, %Y
###
supybot.reply.format.time: %H:%M %Y-%m-%d %Z

###
# Determines whether elapsed times will be given as "1 day, 2 hours, 3
# minutes, and 15 seconds" or as "1d 2h 3m 15s".
#
# Default value: False
###
supybot.reply.format.time.elapsed.short: True

###
# Determines the absolute maximum length of the bot's reply -- no reply
# will be passed through the bot with a length greater than this.
#
# Default value: 131072
###
supybot.reply.maximumLength: 131072

###
# Determines whether the bot will break up long messages into chunks and
# allow users to use the 'more' command to get the remaining chunks.
#
# Default value: True
###
supybot.reply.mores: True

###
# Determines what the maximum number of chunks (for use with the 'more'
# command) will be.
#
# Default value: 50
###
supybot.reply.mores.maximum: 50

###
# Determines how long individual chunks will be. If set to 0, uses our
# super-tweaked, get-the-most-out-of-an-individual-message default.
#
# Default value: 0
###
supybot.reply.mores.length: 0

###
# Determines how many mores will be sent instantly (i.e., without the
# use of the more command, immediately when they are formed). Defaults
# to 1, which means that a more command will be required for all but the
# first chunk.
#
# Default value: 1
###
supybot.reply.mores.instant: 1

###
# Determines whether the bot will send multi-message replies in a single
# message or in multiple messages. For safety purposes (so the bot is
# less likely to flood) it will normally send everything in a single
# message, using mores if necessary.
#
# Default value: True
###
supybot.reply.oneToOne: True

###
# Determines whether the bot will reply with an error message when it is
# addressed but not given a valid command. If this value is False, the
# bot will remain silent, as long as no other plugins override the
# normal behavior.
#
# Default value: True
###
supybot.reply.whenNotCommand: False

###
# Determines whether error messages that result from bugs in the bot
# will show a detailed error message (the uncaught exception) or a
# generic error message.
#
# Default value: False
###
supybot.reply.error.detailed: False

###
# Determines whether the bot will send error messages to users in
# private. You might want to do this in order to keep channel traffic to
# minimum. This can be used in combination with
# supybot.reply.error.withNotice.
#
# Default value: False
###
supybot.reply.error.inPrivate: False

###
# Determines whether the bot will send error messages to users via
# NOTICE instead of PRIVMSG. You might want to do this so users can
# ignore NOTICEs from the bot and not have to see error messages; or you
# might want to use it in combination with supybot.reply.errorInPrivate
# so private errors don't open a query window in most IRC clients.
#
# Default value: False
###
supybot.reply.error.withNotice: False

###
# Determines whether the bot will send an error message to users who
# attempt to call a command for which they do not have the necessary
# capability. You may wish to make this True if you don't want users to
# understand the underlying security system preventing them from running
# certain commands.
#
# Default value: False
###
supybot.reply.error.noCapability: False

###
# Determines whether the bot will reply privately when replying in a
# channel, rather than replying to the whole channel.
#
# Default value: False
###
supybot.reply.inPrivate: False

###
# Determines whether the bot will reply with a notice when replying in a
# channel, rather than replying with a privmsg as normal.
#
# Default value: False
###
supybot.reply.withNotice: False

###
# Determines whether the bot will reply with a notice when it is sending
# a private message, in order not to open a /query window in clients.
# This can be overridden by individual users via the user configuration
# variable reply.withNoticeWhenPrivate.
#
# Default value: False
###
supybot.reply.withNoticeWhenPrivate: False

###
# Determines whether the bot will always prefix the user's nick to its
# reply to that user's command.
#
# Default value: True
###
supybot.reply.withNickPrefix: False

###
# Determines whether the bot should attempt to reply to all messages
# even if they don't address it (either via its nick or a prefix
# character). If you set this to True, you almost certainly want to set
# supybot.reply.whenNotCommand to False.
#
# Default value: False
###
supybot.reply.whenNotAddressed: False

###
# Determines whether the bot will allow you to send channel-related
# commands outside of that channel. Sometimes people find it confusing
# if a channel-related command (like Filter.outfilter) changes the
# behavior of the channel but was sent outside the channel itself.
#
# Default value: False
###
supybot.reply.requireChannelCommandsToBeSentInChannel: False

###
# Supybot normally replies with the full help whenever a user misuses a
# command. If this value is set to True, the bot will only reply with
# the syntax of the command (the first line of the help) rather than the
# full help.
#
# Default value: False
###
supybot.reply.showSimpleSyntax: False

###
# Determines what prefix characters the bot will reply to. A prefix
# character is a single character that the bot will use to determine
# what messages are addressed to it; when there are no prefix characters
# set, it just uses its nick. Each character in this string is
# interpreted individually; you can have multiple prefix chars
# simultaneously, and if any one of them is used as a prefix the bot
# will assume it is being addressed.
#
# Default value:
###
supybot.reply.whenAddressedBy.chars:

###
# Determines what strings the bot will reply to when they are at the
# beginning of the message. Whereas prefix.chars can only be one
# character (although there can be many of them), this variable is a
# space-separated list of strings, so you can set something like '@@ ??'
# and the bot will reply when a message is prefixed by either @@ or ??.
#
# Default value:
###
supybot.reply.whenAddressedBy.strings:

###
# Determines whether the bot will reply when people address it by its
# nick, rather than with a prefix character.
#
# Default value: True
###
supybot.reply.whenAddressedBy.nick: False

###
# Determines whether the bot will reply when people address it by its
# nick at the end of the message, rather than at the beginning.
#
# Default value: False
###
supybot.reply.whenAddressedBy.nick.atEnd: False

###
# Determines what extra nicks the bot will always respond to when
# addressed by, even if its current nick is something else.
#
# Default value:
###
supybot.reply.whenAddressedBy.nicks:

###
# Determines whether the bot will unidentify someone when that person
# changes his or her nick. Setting this to True will cause the bot to
# track such changes. It defaults to False for a little greater
# security.
#
# Default value: False
###
supybot.followIdentificationThroughNickChanges: False

###
# Determines whether the bot will always join a channel when it's
# invited. If this value is False, the bot will only join a channel if
# the user inviting it has the 'admin' capability (or if it's explicitly
# told to join the channel using the Admin.join command)
#
# Default value: False
###
supybot.alwaysJoinOnInvite: False

###
# Determines what message the bot replies with when a command succeeded.
# If this configuration variable is empty, no success message will be
# sent.
###
supybot.replies.success: The operation succeeded.

###
# Determines what error message the bot gives when it wants to be
# ambiguous.
###
supybot.replies.error: An error has occurred and has been logged. Please\
contact this bot's administrator for more\
information.

###
# Determines what message the bot replies with when someone tries to use
# a command that requires being identified or having a password and
# neither credential is correct.
###
supybot.replies.incorrectAuthentication: Your hostmask doesn't match or your\
password is wrong.

###
# Determines what error message the bot replies with when someone tries
# to accessing some information on a user the bot doesn't know about.
###
supybot.replies.noUser: I can't find %s in my user database. If you didn't\
give a user name, then I might not know what your\
user is, and you'll need to identify before this\
command might work.

###
# Determines what error message the bot replies with when someone tries
# to do something that requires them to be registered but they're not
# currently recognized.
###
supybot.replies.notRegistered: You must be registered to use this command.\
If you are already registered, you must\
either identify (using the identify command)\
or add a hostmask matching your current\
hostmask (using the "hostmask add" command).

###
# Determines what error message is given when the bot is telling someone
# they aren't cool enough to use the command they tried to use.
###
supybot.replies.noCapability: You don't have the %s capability. If you think\
that you should have this capability, be sure\
that you are identified before trying again.\
The 'whoami' command can tell you if you're\
identified.

###
# Determines what generic error message is given when the bot is telling
# someone that they aren't cool enough to use the command they tried to
# use, and the author of the code calling errorNoCapability didn't
# provide an explicit capability for whatever reason.
###
supybot.replies.genericNoCapability: You're missing some capability you\
need. This could be because you\
actually possess the anti-capability\
for the capability that's required of\
you, or because the channel provides\
that anti-capability by default, or\
because the global capabilities include\
that anti-capability. Or, it could be\
because the channel or\
supybot.capabilities.default is set to\
False, meaning that no commands are\
allowed unless explicitly in your\
capabilities. Either way, you can't do\
what you want to do.

###
# Determines what error messages the bot sends to people who try to do
# things in a channel that really should be done in private.
###
supybot.replies.requiresPrivacy: That operation cannot be done in a channel.

###
# Determines what message the bot sends when it thinks you've
# encountered a bug that the developers don't know about.
###
supybot.replies.possibleBug: This may be a bug. If you think it is, please\
file a bug report at .

###
# A floating point number of seconds to throttle snarfed URLs, in order
# to prevent loops between two bots snarfing the same URLs and having
# the snarfed URL in the output of the snarf message.
#
# Default value: 10.0
###
supybot.snarfThrottle: 10.0

###
# Determines the number of seconds between running the upkeep function
# that flushes (commits) open databases, collects garbage, and records
# some useful statistics at the debugging level.
#
# Default value: 3600
###
supybot.upkeepInterval: 3600

###
# Determines whether the bot will periodically flush data and
# configuration files to disk. Generally, the only time you'll want to
# set this to False is when you want to modify those configuration files
# by hand and don't want the bot to flush its current version over your
# modifications. Do note that if you change this to False inside the
# bot, your changes won't be flushed. To make this change permanent, you
# must edit the registry yourself.
#
# Default value: True
###
supybot.flush: True

###
# Determines what characters are valid for quoting arguments to commands
# in order to prevent them from being tokenized.
#
# Default value: "
###
supybot.commands.quotes: "

###
# Determines whether the bot will allow nested commands, which rule. You
# definitely should keep this on.
#
# Default value: True
###
supybot.commands.nested: True

###
# Determines what the maximum number of nested commands will be; users
# will receive an error if they attempt commands more nested than this.
#
# Default value: 10
###
supybot.commands.nested.maximum: 10

###
# Supybot allows you to specify what brackets are used for your nested
# commands. Valid sets of brackets include [], <>, and {} (). [] has
# strong historical motivation, as well as being the brackets that don't
# require shift. <> or () might be slightly superior because they cannot
# occur in a nick. If this string is empty, nested commands will not be
# allowed in this channel.
#
# Default value: []
###
supybot.commands.nested.brackets: []

###
# Supybot allows nested commands. Enabling this option will allow nested
# commands with a syntax similar to UNIX pipes, for example: 'bot: foo |
# bar'.
#
# Default value: False
###
supybot.commands.nested.pipeSyntax: False

###
# Determines what commands have default plugins set, and which plugins
# are set to be the default for each of those commands.
###
supybot.commands.defaultPlugins.addcapability: Admin
supybot.commands.defaultPlugins.capabilities: User
supybot.commands.defaultPlugins.disable: Owner
supybot.commands.defaultPlugins.enable: Owner
supybot.commands.defaultPlugins.help: Misc
supybot.commands.defaultPlugins.ignore: Admin

###
# Determines what plugins automatically get precedence over all other
# plugins when selecting a default plugin for a command. By default,
# this includes the standard loaded plugins. You probably shouldn't
# change this if you don't know what you're doing; if you do know what
# you're doing, then also know that this set is case-sensitive.
#
# Default value: Plugin Admin Misc User Owner Config Channel
###
supybot.commands.defaultPlugins.importantPlugins: Plugin Admin Misc User Owner Config Channel
supybot.commands.defaultPlugins.list: Misc
supybot.commands.defaultPlugins.reload: Owner
supybot.commands.defaultPlugins.removecapability: Admin
supybot.commands.defaultPlugins.unignore: Admin

###
# Determines what commands are currently disabled. Such commands will
# not appear in command lists, etc. They will appear not even to exist.
#
# Default value:
###
supybot.commands.disabled:

###
# Determines whether the bot will defend itself against command-
# flooding.
#
# Default value: True
###
supybot.abuse.flood.command: True

###
# Determines how many commands users are allowed per minute. If a user
# sends more than this many commands in any 60 second period, he or she
# will be ignored for supybot.abuse.flood.command.punishment seconds.
#
# Default value: 12
###
supybot.abuse.flood.command.maximum: 12

###
# Determines how many seconds the bot will ignore users who flood it
# with commands.
#
# Default value: 300
###
supybot.abuse.flood.command.punishment: 300

###
# Determines whether the bot will defend itself against invalid command-
# flooding.
#
# Default value: True
###
supybot.abuse.flood.command.invalid: True

###
# Determines how many invalid commands users are allowed per minute. If
# a user sends more than this many invalid commands in any 60 second
# period, he or she will be ignored for
# supybot.abuse.flood.command.invalid.punishment seconds. Typically,
# this value is lower than supybot.abuse.flood.command.maximum, since
# it's far less likely (and far more annoying) for users to flood with
# invalid commands than for them to flood with valid commands.
#
# Default value: 5
###
supybot.abuse.flood.command.invalid.maximum: 5

###
# Determines how many seconds the bot will ignore users who flood it
# with invalid commands. Typically, this value is higher than
# supybot.abuse.flood.command.punishment, since it's far less likely
# (and far more annoying) for users to flood witih invalid commands than
# for them to flood with valid commands.
#
# Default value: 600
###
supybot.abuse.flood.command.invalid.punishment: 600

###
# Determines the default length of time a driver should block waiting
# for input.
#
# Default value: 1.0
###
supybot.drivers.poll: 1.0

###
# Determines what driver module the bot will use. Socket, a simple
# driver based on timeout sockets, is used by default because it's
# simple and stable. Twisted is very stable and simple, and if you've
# got Twisted installed, is probably your best bet.
#
# Default value: default
###
supybot.drivers.module: default

###
# Determines the maximum time the bot will wait before attempting to
# reconnect to an IRC server. The bot may, of course, reconnect earlier
# if possible.
#
# Default value: 300.0
###
supybot.drivers.maxReconnectWait: 300.0

###
# Determines what directory configuration data is put into.
#
# Default value: conf
###
supybot.directories.conf: /home/supybot/pitivi/conf

###
# Determines what directory data is put into.
#
# Default value: data
###
supybot.directories.data: /home/supybot/pitivi/data

###
# Determines what directory temporary files are put into.
#
# Default value: tmp
###
supybot.directories.data.tmp: /home/supybot/pitivi/data/tmp

###
# Determines what directory backup data is put into.
#
# Default value: backup
###
supybot.directories.backup: /home/supybot/pitivi/backup

###
# Determines what directories the bot will look for plugins in. Accepts
# a comma-separated list of strings. This means that to add another
# directory, you can nest the former value and add a new one. E.g. you
# can say: bot: 'config supybot.directories.plugins [config
# supybot.directories.plugins], newPluginDirectory'.
#
# Default value:
###
supybot.directories.plugins: /home/supybot/pitivi/plugins

###
# Determines what directory the bot will store its logfiles in.
#
# Default value: logs
###
supybot.directories.log: /home/supybot/pitivi/logs

###
# Determines what plugins will be loaded.
#
# Default value:
###
supybot.plugins: Web Admin Misc Bugzilla User Owner Config Channel

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Admin: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Admin.public: True

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Bugzilla: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Bugzilla.public: True

###
# Determines whether the bug snarfer will be enabled, such that any
# Bugzilla URLs and bug ### seen in the channel will have their
# information reported into the channel.
#
# Default value: False
###
supybot.plugins.Bugzilla.bugSnarfer: True

###
# Users often say "bug XXX" several times in a row, in a channel. If
# "bug XXX" has been said in the last (this many) seconds, don't fetch
# its data again. If you change the value of this variable, you must
# reload this plugin for the change to take effect.
#
# Default value: 300
###
supybot.plugins.Bugzilla.bugSnarferTimeout: 300

###
# The fields to list when describing a bug, after the URL.
#
# Default value: bug_severity priority target_milestone assigned_to bug_status short_desc
###
supybot.plugins.Bugzilla.bugFormat: bug_severity priority target_milestone assigned_to bug_status short_desc

###
# The fields to list when describing an attachment after announcing a
# change to that attachment.
#
# Default value: type desc filename
###
supybot.plugins.Bugzilla.attachFormat: type desc filename

###
# How various messages should be formatted in terms of bold, colors,
# etc.
###

###
# When the plugin reports that something has changed on a bug, how
# should that string be formatted?
#
# Default value: teal
###
supybot.plugins.Bugzilla.format.change: teal

###
# When the plugin reports the details of an attachment, how should we
# format that string?
#
# Default value: green
###
supybot.plugins.Bugzilla.format.attachment: green

###
# When the plugin reports the details of a bug, how should we format
# that string?
#
# Default value: red
###
supybot.plugins.Bugzilla.format.bug: red

###
# The number of results to show when using the "query" command.
#
# Default value: 5
###
supybot.plugins.Bugzilla.queryResultLimit: 5

###
# A path to the mbox that we should be watching for bugmail.
#
# Default value:
###
supybot.plugins.Bugzilla.mbox: /var/mail/supybot

###
# How many seconds should we wait between polling the mbox?
#
# Default value: 10
###
supybot.plugins.Bugzilla.mboxPollTimeout: 10

###
# Various messages that can be re-formatted as you wish. If a message
# takes a format string, the available format variables are: product,
# component, bug_id, attach_id, and changer)
###

###
# What the bot will say when somebody adds a new attachment to a bug.
#
# Default value: %(changer)s added attachment %(attach_id)d to bug %(bug_id)d
###
supybot.plugins.Bugzilla.messages.newAttachment: %(changer)s added attachment %(attach_id)d to bug %(bug_id)d

###
# What the bot will say when a new bug is filed.
#
# Default value: New %(product)s bug %(bug_id)d filed by %(changer)s.
###
supybot.plugins.Bugzilla.messages.newBug: New %(product)s bug %(bug_id)d filed by %(changer)s.

###
# How should we describe it when somebody requests a flag without
# specifying a requestee? This should probably start with "from." It can
# also be entirely empty, if you want.
#
# Default value: from the wind
###
supybot.plugins.Bugzilla.messages.noRequestee: from the wind

###
# The various Bugzilla installations that have been created with the
# 'add' command.
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas: gnome

###
# Determines the URL to this Bugzilla installation. This must be
# identical to the urlbase (or sslbase) parameter used by the
# installation. (The url that shows up in emails.) It must end with a
# forward slash.
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas.gnome.url: https://bugzilla.gnome.org/

###
# Additional search terms in QuickSearch format, that will be added to
# every search done with "query" against this installation.
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas.gnome.queryTerms:

###
# Should *all* changes be reported to this channel?
#
# Default value: False
###
supybot.plugins.Bugzilla.bugzillas.gnome.watchedItems.all: False

###
# Whose changes should be reported to this channel?
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas.gnome.watchedItems.changer:

###
# What components should be reported to this channel?
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas.gnome.watchedItems.component:

###
# What products should be reported to this channel?
#
# Default value:
###
supybot.plugins.Bugzilla.bugzillas.gnome.watchedItems.product: pitivi

###
# The names of fields, as they appear in bugmail, that should be
# reported to this channel.
#
# Default value: newBug, newAttach, Flags, Attachment Flags, Resolution, Product, Component
###
supybot.plugins.Bugzilla.bugzillas.gnome.reportedChanges: newBug

###
# Some Bugzilla installations have gdb stack traces in comments. If you
# turn this on, the bot will report some basic details of any trace that
# shows up in the comments of a new bug.
#
# Default value: False
###
supybot.plugins.Bugzilla.bugzillas.gnome.traces.report: False

###
# Some functions are useless to report, from a stack trace. This
# contains a list of function names to skip over when reporting traces
# to the channel.
#
# Default value: __kernel_vsyscall raise abort ??
###
supybot.plugins.Bugzilla.bugzillas.gnome.traces.ignoreFunctions: __kernel_vsyscall raise abort ??

###
# How many stack frames should be reported from the crash?
#
# Default value: 5
###
supybot.plugins.Bugzilla.bugzillas.gnome.traces.frameLimit: 5

###
# If commands don't specify what installation to use, then which
# installation should we use?
#
# Default value:
###
supybot.plugins.Bugzilla.defaultBugzilla: gnome

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Channel: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Channel.public: True

###
# Determines whether the bot will always try to rejoin a channel
# whenever it's kicked from the channel.
#
# Default value: True
###
supybot.plugins.Channel.alwaysRejoin: True

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Config: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Config.public: True

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Misc: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Misc.public: True

###
# Determines whether the bot will list private plugins with the list
# command if given the --private switch. If this is disabled, non-owner
# users should be unable to see what private plugins are loaded.
#
# Default value: True
###
supybot.plugins.Misc.listPrivatePlugins: False

###
# Determines the format string for timestamps in the Misc.last command.
# Refer to the Python documentation for the time module to see what
# formats are accepted. If you set this variable to the empty string,
# the timestamp will not be shown.
#
# Default value: [%H:%M:%S]
###
supybot.plugins.Misc.timestampFormat: [%H:%M:%S]

###
# Determines whether or not the timestamp will be included in the output
# of last when it is part of a nested command
#
# Default value: False
###
supybot.plugins.Misc.last.nested.includeTimestamp: False

###
# Determines whether or not the nick will be included in the output of
# last when it is part of a nested command
#
# Default value: False
###
supybot.plugins.Misc.last.nested.includeNick: False

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Owner: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Owner.public: True

###
# Determines what quit message will be used by default. If the quit
# command is called without a quit message, this will be used. If this
# value is empty, the nick of the person giving the quit command will be
# used.
#
# Default value:
###
supybot.plugins.Owner.quitMsg:

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.User: True

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.User.public: True

###
# Determines whether this plugin is loaded by default.
###
supybot.plugins.Web: False

###
# Determines whether this plugin is publicly visible.
#
# Default value: True
###
supybot.plugins.Web.public: True

###
# Determines whether the bot will output the HTML title of URLs it sees
# in the channel.
#
# Default value: False
###
supybot.plugins.Web.titleSnarfer: False

###
# Determines what URLs are to be snarfed and stored in the database in
# the channel; URLs matching the regexp given will not be snarfed. Give
# the empty string if you have no URLs that you'd like to exclude from
# being snarfed.
#
# Default value:
###
supybot.plugins.Web.nonSnarfingRegexp:

###
# Determines the maximum number of bytes the bot will download via the
# 'fetch' command in this plugin.
#
# Default value: 0
###
supybot.plugins.Web.fetch.maximum: 0

###
# Determines whether the bot will always load important plugins (Admin,
# Channel, Config, Misc, Owner, and User) regardless of what their
# configured state is. Generally, if these plugins are configured not to
# load, you didn't do it on purpose, and you still want them to load.
# Users who don't want to load these plugins are smart enough to change
# the value of this variable appropriately :)
#
# Default value: True
###
supybot.plugins.alwaysLoadImportant: True

###
# Determines what databases are available for use. If this value is not
# configured (that is, if its value is empty) then sane defaults will be
# provided.
#
# Default value: sqlite anydbm cdb flat pickle
###
supybot.databases:

###
# Determines what filename will be used for the users database. This
# file will go into the directory specified by the
# supybot.directories.conf variable.
#
# Default value: users.conf
###
supybot.databases.users.filename: users.conf

###
# Determines how long it takes identification to time out. If the value
# is less than or equal to zero, identification never times out.
#
# Default value: 0
###
supybot.databases.users.timeoutIdentification: 0

###
# Determines whether the bot will allow users to unregister their users.
# This can wreak havoc with already-existing databases, so by default we
# don't allow it. Enable this at your own risk. (Do also note that this
# does not prevent the owner of the bot from using the unregister
# command.)
#
# Default value: False
###
supybot.databases.users.allowUnregistration: False

###
# Determines what filename will be used for the ignores database. This
# file will go into the directory specified by the
# supybot.directories.conf variable.
#
# Default value: ignores.conf
###
supybot.databases.ignores.filename: ignores.conf

###
# Determines what filename will be used for the channels database. This
# file will go into the directory specified by the
# supybot.directories.conf variable.
#
# Default value: channels.conf
###
supybot.databases.channels.filename: channels.conf

###
# Determines whether database-based plugins that can be channel-specific
# will be so. This can be overridden by individual channels. Do note
# that the bot needs to be restarted immediately after changing this
# variable or your db plugins may not work for your channel; also note
# that you may wish to set
# supybot.databases.plugins.channelSpecific.link appropriately if you
# wish to share a certain channel's databases globally.
#
# Default value: True
###
supybot.databases.plugins.channelSpecific: False

###
# Determines what channel global (non-channel-specific) databases will
# be considered a part of. This is helpful if you've been running
# channel-specific for awhile and want to turn the databases for your
# primary channel into global databases. If
# supybot.databases.plugins.channelSpecific.link.allow prevents linking,
# the current channel will be used. Do note that the bot needs to be
# restarted immediately after changing this variable or your db plugins
# may not work for your channel.
#
# Default value: #
###
supybot.databases.plugins.channelSpecific.link: #

###
# Determines whether another channel's global (non-channel-specific)
# databases will be allowed to link to this channel's databases. Do note
# that the bot needs to be restarted immediately after changing this
# variable or your db plugins may not work for your channel.
#
# Default value: True
###
supybot.databases.plugins.channelSpecific.link.allow: True

###
# Determines whether CDB databases will be allowed as a database
# implementation.
#
# Default value: True
###
supybot.databases.types.cdb: True

###
# Determines how often CDB databases will have their modifications
# flushed to disk. When the number of modified records is greater than
# this part of the number of unmodified records, the database will be
# entirely flushed to disk.
#
# Default value: 0.5
###
supybot.databases.types.cdb.maximumModifications: 0.5

###
# Determines what will be used as the default banmask style.
#
# Default value: host user
###
supybot.protocols.irc.banmask: host user

###
# Determines whether the bot will strictly follow the RFC; currently
# this only affects what strings are considered to be nicks. If you're
# using a server or a network that requires you to message a nick such
# as services@this.network.server then you you should set this to False.
#
# Default value: False
###
supybot.protocols.irc.strictRfc: False

###
# Determines what user modes the bot will request from the server when
# it first connects. Many people might choose +i; some networks allow
# +x, which indicates to the auth services on those networks that you
# should be given a fake host.
#
# Default value:
###
supybot.protocols.irc.umodes:

###
# Determines what vhost the bot will bind to before connecting to the
# IRC server.
#
# Default value:
###
supybot.protocols.irc.vhost:

###
# Determines how many old messages the bot will keep around in its
# history. Changing this variable will not take effect until the bot is
# restarted.
#
# Default value: 1000
###
supybot.protocols.irc.maxHistoryLength: 1000

###
# A floating point number of seconds to throttle queued messages -- that
# is, messages will not be sent faster than once per throttleTime
# seconds.
#
# Default value: 1.0
###
supybot.protocols.irc.throttleTime: 1.0

###
# Determines whether the bot will send PINGs to the server it's
# connected to in order to keep the connection alive and discover
# earlier when it breaks. Really, this option only exists for debugging
# purposes: you always should make it True unless you're testing some
# strange server issues.
#
# Default value: True
###
supybot.protocols.irc.ping: True

###
# Determines the number of seconds between sending pings to the server,
# if pings are being sent to the server.
#
# Default value: 120
###
supybot.protocols.irc.ping.interval: 120

###
# Determines whether the bot will refuse duplicate messages to be queued
# for delivery to the server. This is a safety mechanism put in place to
# prevent plugins from sending the same message multiple times; most of
# the time it doesn't matter, unless you're doing certain kinds of
# plugin hacking.
#
# Default value: False
###
supybot.protocols.irc.queuing.duplicates: False

###
# Determines how many seconds must elapse between JOINs sent to the
# server.
#
# Default value: 0.0
###
supybot.protocols.irc.queuing.rateLimit.join: 0.0

###
# Determines how many bytes the bot will 'peek' at when looking through
# a URL for a doctype or title or something similar. It'll give up after
# it reads this many bytes, even if it hasn't found what it was looking
# for.
#
# Default value: 4096
###
supybot.protocols.http.peekSize: 4096

###
# Determines what proxy all HTTP requests should go through. The value
# should be of the form 'host:port'.
#
# Default value:
###
supybot.protocols.http.proxy:

###
# Determines whether the bot will ignore unregistered users by default.
# Of course, that'll make it particularly hard for those users to
# register or identify with the bot, but that's your problem to solve.
#
# Default value: False
###
supybot.defaultIgnore: False

###
# A string that is the external IP of the bot. If this is the empty
# string, the bot will attempt to find out its IP dynamically (though
# sometimes that doesn't work, hence this variable).
#
# Default value:
###
supybot.externalIP:

###
# Determines what the default timeout for socket objects will be. This
# means that *all* sockets will timeout when this many seconds has gone
# by (unless otherwise modified by the author of the code that uses the
# sockets).
#
# Default value: 10
###
supybot.defaultSocketTimeout: 10

###
# Determines what file the bot should write its PID (Process ID) to, so
# you can kill it more easily. If it's left unset (as is the default)
# then no PID file will be written. A restart is required for changes to
# this variable to take effect.
#
# Default value:
###
supybot.pidFile:

###
# Determines whether the bot will automatically thread all commands.
#
# Default value: False
###
supybot.debug.threadAllCommands: False

###
# Determines whether the bot will automatically flush all flushers
# *very* often. Useful for debugging when you don't know what's breaking
# or when, but think that it might be logged.
#
# Default value: False
###
supybot.debug.flushVeryOften: False

###
# Determines what the bot's logging format will be. The relevant
# documentation on the available formattings is Python's documentation
# on its logging module.
#
# Default value: %(levelname)s %(asctime)s %(name)s %(message)s
###
supybot.log.format: %(levelname)s %(asctime)s %(name)s %(message)s

###
# Determines what the minimum priority level logged to file will be. Do
# note that this value does not affect the level logged to stdout; for
# that, you should set the value of supybot.log.stdout.level. Valid
# values are DEBUG, INFO, WARNING, ERROR, and CRITICAL, in order of
# increasing priority.
#
# Default value: INFO
###
supybot.log.level: INFO

###
# Determines the format string for timestamps in logfiles. Refer to the
# Python documentation for the time module to see what formats are
# accepted. If you set this variable to the empty string, times will be
# logged in a simple seconds-since-epoch format.
#
# Default value: %Y-%m-%dT%H:%M:%S
###
supybot.log.timestampFormat: %Y-%m-%dT%H:%M:%S

###
# Determines whether the bot will log to stdout.
#
# Default value: True
###
supybot.log.stdout: True

###
# Determines whether the bot's logs to stdout (if enabled) will be
# colorized with ANSI color.
#
# Default value: False
###
supybot.log.stdout.colorized: True

###
# Determines whether the bot will wrap its logs when they're output to
# stdout.
#
# Default value: True
###
supybot.log.stdout.wrap: False

###
# Determines what the bot's logging format will be. The relevant
# documentation on the available formattings is Python's documentation
# on its logging module.
#
# Default value: %(levelname)s %(asctime)s %(message)s
###
supybot.log.stdout.format: %(levelname)s %(asctime)s %(message)s

###
# Determines what the minimum priority level logged will be. Valid
# values are DEBUG, INFO, WARNING, ERROR, and CRITICAL, in order of
# increasing priority.
#
# Default value: INFO
###
supybot.log.stdout.level: DEBUG

###
# Determines whether the bot will separate plugin logs into their own
# individual logfiles.
#
# Default value: False
###
supybot.log.plugins.individualLogfiles: False

###
# Determines what the bot's logging format will be. The relevant
# documentation on the available formattings is Python's documentation
# on its logging module.
#
# Default value: %(levelname)s %(asctime)s %(message)s
###
supybot.log.plugins.format: %(levelname)s %(asctime)s %(message)s

###
# These are the capabilities that are given to everyone by default. If
# they are normal capabilities, then the user will have to have the
# appropriate anti-capability if you want to override these
# capabilities; if they are anti-capabilities, then the user will have
# to have the actual capability to override these capabilities. See
# docs/CAPABILITIES if you don't understand why these default to what
# they do.
#
# Default value: -owner -admin -trusted
###
supybot.capabilities: -owner -admin -trusted

###
# Determines whether the bot by default will allow users to have a
# capability. If this is disabled, a user must explicitly have the
# capability for whatever command he wishes to run.
#
# Default value: True
###
supybot.capabilities.default: False

Make it dance

Now start your bot from the command line. This way you can see the debug log messages, in case you need to figure out why it does not work.

sudo -u supybot supybot /home/supybot/pitivi/bot.conf


Finally, create /lib/systemd/system/supybot.service to have it started automatically.
[Unit]
Description=Pitivi IRC bot

[Service]
User=supybot
ExecStart=/usr/bin/supybot /home/supybot/pitivi/bot.conf
UMask=0007
Restart=on-abort
StartLimitInterval=5m
StartLimitBurst=1

[Install]
WantedBy=multi-user.target

Remember to start it and enable it to start automatically.
systemctl start supybot
systemctl enable supybot


Alternatively, create a file in /etc/init/ so Supybot is started automatically when the system starts. I probably copied the file below from somewhere, but I don't remember from where.

# This IRC bot serves #pitivi.
description "Pitivi IRC bot"

# I got this from mysql.conf, you might want to have a look
# at other files in /etc/init/ and copy a section which
# looks appropriate. Basically it should start the daemon
# after the network is started.
start on (net-device-up
and local-filesystems
and runlevel [2345])
stop on runlevel [016]

# Restart if it dies unexpectedly. Should not happen.
respawn

# Make sure the binary exists.
# It's recommended you install supybot from the current git
# HEAD, because no features are being worked on, and it
# should be stable: http://sf.net/projects/supybot/develop
# In this case, the binary is in /usr/local/bin/supybot.
# This may differ if you are using, the package included in
# your Linux distribution, for example.
pre-start script
test -x /usr/local/bin/supybot || { stop; exit 0; }
end script

# Output to the console whatever it outputs.
console output

# Run the bot with the specified config file.
#
# The bot does not need to run as a daemon, unless
# there are other jobs depending on its sucessful start,
# for example. If there are, you should add "expect fork",
# and specify --daemon to the command line, and hope that
# it works, because:
# "One needs to be very careful with the expect stanza
# to avoid confusing Upstart: the program must fork in
# precisely the expected way." ion
#
# To create the supybot system user and system group, and
# add yourself to the group so you can easily edit files
# run:
# addgroup --system supybot
# adduser --system --ingroup supybot supybot
exec sudo -u supybot /usr/local/bin/supybot /home/supybot/pitivi/bot.conf


Congratulations! Send me an email and tell me how happy you are that you have your bot. ;)

Polishing Pitivi's ruler



In Pitivi, the ruler is displayed above the timeline to show the times corresponding with the current view. A series of H:MM:SS.XXX timestamps on a ruler might leave the impression that only trained professionals are supposed to use it. I had trouble reading the timestamps and looked for ways to make the ruler more useful. Read below for the story.

Pitivi ruler, Dec 2013

Relevant parts

Around the New Year 2013-2014 I thought about highlighting the relevant parts in the timestamp. For example, if you have 0:00:05.000 and then 0:00:10.000, you have to look quite a bit until you notice what changes from one to the other. In this case the "10" should be highlighted because that's different than the previous timestamp. This way it's easier to see what an interval represents. Jeff liked the idea and the commit went in.

The ruler being more useful, I started to look more at it while using Pitivi. One week later, after 6 code cleanup commits, the millis were being displayed with a smaller font, so they can be ignored more easily. One hour later though, the hours and millis were being displayed only when useful:
  • The hour is displayed only if greater than 0. 
  • The millis are displayed only when the zoom level is high enough that millis other than “.000” start to show up in the timestamps. This got improved later!
The shorter timestamps looked good so the changes went in.

Guessing most projects are less than one hour long and most of the time users don't use zoom levels where milliseconds matter—this was already a big improvement, it’s much easier to see “MM:SS” than “0:MM:SS.000”.

Pitivi ruler zoomed out, Jan 2014

Dividing an interval

An “interval” on the ruler is the interval at which the timestamps are shown. At different zoom levels, the length of the interval is picked automatically out of a hardcoded list, so you see an optimum number of timestamps. It was awkward that the displayed intervals were always divided in 10 parts. While it makes sense for a 10 seconds interval to be divided by 10, it’s not very useful when a 30 minutes interval is divided by 10.

It was easy to define the tick frequency for each of the hardcoded intervals, but it looked awkward for most of the zoom levels. Previously we clearly preferred largish interval sizes (so the interval can be divided in 10 smaller but still visible units) but it was not so nice anymore when a large interval is divided only in 2 units. Some fine-tune of the minimum interval length and the minimum division length was required. The smaller timestamps fit great with the smaller intervals:

Dividing by 2 is enough for some intervals, Dec 2015

Timestamp shape

While fine-tuning the minimum interval and interval division size, I realized that when displaying millis, it’s useful to display only the millis, except for the full second timestamps when only [H:]MM:SS is displayed. This way it’s much easier to see where the full seconds are, because “00:01” looks quite different shape-wise than “.500” which is displayed with a smaller font. Luckily, by keeping all the timestamps short (“.900” is the shortest and “9:00:00” is the longest), it was possible to have a simple formula for choosing the optimum interval per zoom level.

Pitivi ruler zoomed in, Jan 2016

The commit went in, along with a cherry.

Some did not like the pear-shaped playhead though, so we later replaced it with an empty diamond.

Pitivi playhead, Apr 2016

Start Pitivi and look at the ruler, zooming in and out, a nice feeling starts bubbling up inside.

Until we wrap up 0.96, you can already see the ruler in action by downloading the Pitivi bundle! BTW, the bundle already includes the proxy files functionality which allows using any video format reliably. Read: no more artifacts when using MTS files. When compared, the ruler polishing I described above is just me playing in the sand. The proxy files functionality brings Pitivi much closer to 1.0. Please try it out and tell us how it works for you! :)

If you are still here, see maybe the entire history of Pitivi’s ruler.

February 27, 2018

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 https://gitlab.gnome.org/GNOME/pitivi.

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.

September 22, 2017

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.

GSoC

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.

1.0

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.

September 14, 2017

Cheese's pipeline

I have been reading the source code of Cheese. I wanted to get an idea of how it works. So this is what I understand. Below the diagram you will see an explanation of this, if you know about GStreamer you may want to skip the explanation.

Developer Console I

Cheese reads some data from the selected webcam device using the bin camera_source. In parallel, Cheese uses an autoaudiosrc to capture data from the sound card. The data from the webcam is sent to a tee which work is to duplicate the output.

Firstly, one of the outputs of this tee is passed to an element called element_bin_preview (this also uses a tee of nine outputs… but that’s not showed in the diagram). An elements_bin_preview has 9 sink pads. The output that flows out from there is (for each sink pad) passed to a filter and finally to a cluttersink. Its name on itself is just descriptive, elements_bin_preview is used to preview the effects in that 3x3 “grid” used for Cheese when you click on the “Effects” button.

Secondly, the data that flows from the other sink pad of the tee is sent to an element called current_selected_filter which is the filter that has been currently selected by the user by clicking the grid of effects in Cheese. In case of recording video, the output that flows out from one of the sink pads of the tee is sent in parallel with the autoaudiosrc to an encodebin which (of course) encodes and mixes to pass it to a filesink so you have the result (a video file) on your disk. In case of using the “burst mode” in Cheese, the second output of the tee is used to be passed to a filesink. The filesink can then capture some bunch of frames (by default 4 in Cheese) saving the output in the disk. filesink usually receives an index in its filename, so when you take a picture with Cheese, you will usually see that base names of file names have a number from 1 to 4 in the sufix when using “Burst mode”. Finally, the third output of the sink is used to show the output of the camera with the filter applied in the Cheese main window using a cluttersink element.

August 28, 2017

GSoC '17 - Final Report

This summer as part of Google Summer of Code 2017, I worked on the project “Pitivi: Color correction interface using three chromatic wheels”. As GSoC concludes, I’m writing this post as part of my final submission.

Status of the project

I worked on the task T3263 to setup the infrastructure to allow special effect interfaces. Previously, Pitivi simply autogenerated the UI for an effect based on the effect properties. Differential revision D1744 sets up the API to allow custom UI for an effect and D1777 improves the mechanism by providing a way to have a few custom widgets for effect properties while autogenerating the rest of the UI. If you’d like to know exactly how this mechanism developed and how it works, please refer to my GSoC Phase 1 Progress Report.

As an example to use this custom widget API, I worked on the task T7761, implementing a simple UI for the alpha filter effect - differential revision D1745

And finally, I worked on the task T2372 making the ‘Color correction interface using three chromatic wheels’ for the 3 point color balance effect. I had to learn how to make custom Gtk widgets and cairo for making the color wheel widget. Being new to this task, I referred to the GIMP’s color wheel widget and ended up making a standalone version of it removing dependencies like libgimp.

color wheel widget

However, we decided to use the GtkHSV for now instead of my implementation because although GtkHSV has now been deprecated it is still available as part of Gtk3 and is far more superior than my basic color wheel. Perhaps, it would be nice if we got the widget from upstream and if not, the alternative is to improve my implemenation of the color wheel widget which can be found here. D1838 holds the new custom UI for the 3 point color balance effect.

I was able to achieve one of the stretch goals of GSoC, task T7810 to implement color picking functionality. Differential revision D1855 introduces the ColorPickerButton which allows picking color from anywhere on the screen. As a result, the ColorPickerButton can be integrated in many places in Pitivi! :)

To summarise, here are the links to my work:

As of now, these revisions have not yet been merged. My immediate task is to follow through the review process to get these revisions merged.

The final product of my Google Summer of Code looks like this!

Final Words

I would like to thank my mentor Mathieu Duponchelle (Mathieu_Du) for guiding me. He’s been really encouraging and thoughtful. A special thank you to both the current maintianers, right from when I started contributing to Pitivi earlier this year, Alexandru Băluț (aleb) and Thibault Saunier (thiblahute) have been extremely helpful. It’s been great working with these people at Pitivi. I’ve had a wonderful journey so far. Ofcourse, this is not the end. My work for GSoC introduces so much more possibility and I would like to explore and continue contributing :)

Until next time.

GSoC 2017 : wrap-up and code submission

This post pretends to summarize what has been done during my project in the Google Summer of Code. This is also my Work Product Submission. The project has consisted on implementing a plugin manager for Pitivi and adding a plugin called the Developer Console.

Libpeas

The first part of my project I worked on the bug 780685. Currently it is not possible to implement a plugin system in Python based applications using Libpeas. I have wrote two patches (attachments 354018 and 354019) that fixes the problem. Get these patches merged was depending on Libpeas mantainer. Unfortunately, although he has already reviewed my code, he is currently disabled to review my patches. Lately, the GNOME Builder mantainer has offered to review my patches in bug 660014. As response to his review, these patches has been proposed: attachment 357644 and attachment 357645. In my opinion, the two set of patches proposed to the Libpeas mantainer and to the GNOME Builder mantainer are ready to merge, but it seems it will take time. This is not a a big obstacle for Pitivi, though, because I have added my patch as a source of Libpeas in the Pitivi’s Flatpak manifest. This has just been merged in Pitivi (see D1746).

Plugin Manager

The development of the Plugin manager consisted firstly on creating a module PluginManager that handles the plugins in Pitivi (see D1748), which also provides the API that exposes the application instance to the plugins. The plugin manager class is configuration-aware (see D1812) so it remembers which plugins were activated or deactivated on the last execution of the program. Then I have created an user interface for it (see D1789. The Preferences Dialog has been extended to list the available plugins and allow activating and deactivating them. It also handles plugins with dependencies as Libpeas does. Also, the Pitivi Preferences Dialog has been modified (see D1853) so plugins can add custom preferences widgets to the Pitivi Preferences Dialog. All the patches linked have just been merged in Pitivi. Other feature that has not been merged yet is one that classifies plugin in system and user plugins.

Plugin Manager UI

Developer Console Plugin

The developer console plugin is based on a Gedit’s plugin calle “pythonconsole”. Initially my project was reusing most of the “pythonconsole” plugin, but lately through many iterations of reviews it has been improved a lot. Gedit’s “pythonconsole” works trying to eval the input command and if it fails then it tries exec. This approach (see D1793) has been improved using the code module. I have added to it autocompletion support (see D1857). Also I have integrated color preferences with the Pitivi Settings and I have added the option to customize the font of the emulated console (see D1790, D1792 and D1828).

Developer Console I

The developer console (that uses code.InteractiveConsole) has access to internal objects on Pitivi. That behavior is achieved by adding a dictionary of locals variables, for example it receives as locals an argument like {"app": app}. The problem with this was that the user can (accidentally) override app to None for example and thus losing the access to the Pitivi’s internal objects. That has been solved by adding a custom class called Namespace that inherits from a dict overriding setitem so whenever the user wants to change the value of app (for example), the console writes an error message to stderr. Also, some “shorcuts” commands has been added for a fast access to objects that my mentor and I think will be frequently used. See D1793 or this old post for an extended explanation.

Developer Console I

This plugin is not merged yet, but some of the patches here has been accepted.

Documentation

Two patches that documents a basic behavior of the console has been proposed. The first patch (see D1858) provides plugin developers a very basic information about how to create a plugin. The second patch is a tutorial that explains how to create a plugin that does something useful that is to remove gaps between clips (see D1859). This patches has not been reviewed yet but my mentor told me that it would be helpful to have documentation, so I did this.

Yes… you can code in Pitivi :)

August 24, 2017

Writing a plugin for Pitivi I

The code I have written have been reviewed a lot. So these days I have been completing some minimal details in my code. My patches that implement the plugin manager for Pitivi has been accepted. The next bunch of patches that are on revision are the ones related to the developer console plugin. I want to thank the dedication that Alexandru Băluț (aleb) put to review my code, because this improve the software. While aleb was reviewing my patches, I have been writing some documentation that will be published later in The Pitivi Developer Documentation, but before that I want to share a simple example about how to write a plugin for Pitivi.

At GUADEC 2017, Christian Hergert gave a talk named “State of the Builder”. As I have said in my previous post this was one of the conferences I was most interested about. Unfortunately, there was a problem with the audio recorder and the video of his talk has not been published on Youtube. But I remember he showed a plugin in which you can play a video in GNOME Builder using GStreamer.

hergertme's tweet

Today I feel on the mood to do something similar. So why not to write a plugin to edit code in Pitivi?

Code Editor

Editing code in Pitivi

Yep… this is a joke and a tutorial at the same time. Let’s start.

Plugins location

User plugins that are from third-party developers should be placed at $HOME/.local/share/pitivi/plugins/.

The .plugin description

The first step to create plugin is to create a plugin description file. By convention, this file should be named module-name.plugin.

[Plugin]
Module=code_editor
Name=Code Editor
Description=A plugin to edit code in Python.
Authors=Example <example@example.com>
website=http://example.foo
Copyright=Copyright © Example
Loader=Python3

For a complete example of a plugin description file, see PeasPluginInfo documentation.

Creating a simple Python module

The only interface available to implement by Pitivi extensions is the Peas.Activatable. Extension modules should implement this interface and internally as soon this module is loaded Pitivi will set to it the object attribute to the Pitivi application object, which will give you access to almost everything.

Now create the file hello_world.py in the same directory of hello-world.py.

class CodeEditor(GObject.GObject, Peas.Activatable):
    __gtype_name__ = 'CodeEditor'
    object = GObject.Property(type=GObject.Object)

    def __init__(self):
        GObject.Object.__init__(self)

    def do_activate(self):
        print("Hello world!")

    def do_deactivate(self):
        print("Bye!")

You’ve just created your first plugin! It will print a message in the terminal when you activate or deactivate the plugin.

Replacing the Pitivi Timeline by a GtkSourceView

The plugin we wrote was bery simple, now we want to do something more complex.

We will rewrite our __init__ function to look like this:

    def __init__(self):
        GObject.Object.__init__(self)
        self.app = None
        self.source_view = None
        self._timeline = None

where self.app will represent the Pitivi application.

Now we want to do something useful when the plugin is activated. So we will replace this method by this:

    def do_activate(self):
        API = self.object
        self.app = API.app

        self._timeline = self.app.gui.timeline_ui.get_child_at(0, 1)
        self.app.gui.timeline_ui.remove(self._timeline)

        self.source_view = GtkSource.View()
        language_manager = GtkSource.LanguageManager()
        language = language_manager.get_language("python3")
        buf = self.source_view.get_buffer()
        buf.set_language(language)
        self.source_view.show()

The API object contains the Pitivi application, so we assign it to self.app just to access it without typing too much. Then we get the Timeline object that is the widget that displays a representation of the GES.Timeline. Then we create a GtkSourceView that is the widget that provides a text editor with features like highlighting (among others). Then we set to it as “python3” as the default language and then set it to the buffer of the GtkSourceView. Finally, we show the source view.

Now we wish to add just these lines to have a better code editor:

        self.source_view.props.show_line_numbers = True
        self.source_view.props.show_right_margin = True

Then the function do_deactivate is called every time we turn off the switch in the plugin manager. We destroy the GtkSourceView so it is removed from its parent, too. Finally we reattach the timeline so the timeline is visible again.

    def do_deactivate(self):
        self.source_view.destroy()
        self.app.gui.timeline_ui.attach(self._timeline, 0, 1, 2, 1)
        self.source_view = None

That’s it. You can do more if you want like adding support for more languages or a button to export the code as a file. You can also add preferences to the Preferences Dialog and add new settings. With this example I want to show you that you can go as far as you want just with imagination and some knowledge about programming.

Full code

from gi.repository import GObject
from gi.repository import GtkSource
from gi.repository import Peas


class CodeEditor(GObject.GObject, Peas.Activatable):
    __gtype_name__ = 'CodeEditor'
    object = GObject.Property(type=GObject.Object)

    def __init__(self):
        GObject.Object.__init__(self)
        self.app = None
        self.source_view = None
        self._timeline = None

    def do_activate(self):
        API = self.object
        self.app = API.app

        self._timeline = self.app.gui.timeline_ui.get_child_at(0, 1)
        self.app.gui.timeline_ui.remove(self._timeline)

        self.source_view = GtkSource.View()
        language_manager = GtkSource.LanguageManager()
        language = language_manager.get_language("python3")
        buf = self.source_view.get_buffer()
        buf.set_language(language)

        self.app.gui.timeline_ui.attach(self.source_view, 0, 1, 2, 1)
        self.source_view.show()

        self.source_view.props.show_line_numbers = True
        self.source_view.props.show_right_margin = True

    def do_deactivate(self):
        self.source_view.destroy()
        self.app.gui.timeline_ui.attach(self._timeline, 0, 1, 2, 1)
        self.source_view = None

As I said this was in part a tutorial and a joke at the same time. So I hope you have enjoyed the post and also I hope the plugin manager gets merged as soon as possible. I am writing serious documentation that will explain more about how to write plugins in Pitivi. I also want to thank to Christian Hergert to take his time to review my patch for Libpeas.

August 16, 2017

GUADEC 2017

One of the things I like the most about GNOME are the annual conferences called GUADEC. You can see in person to the folks you were chatting with on IRC. As I have mentioned in my previous posts, I am an accepted GSoC 2017 student this year, and thus like other students, I was invited to give a lightning talk about my project with Pitivi, that consist on adding a plugin system as I mentioned in other posts. I live in Peru, so the duration of the flight is really long. Actually, I found a great deal by going first to Madrid and then taking other flight to Manchester. From Lima to Amsterdam (the stop of my flight to Madrid) it was about 12 hours, from Amsterdam to Madrid it was about 3 hours and from Madrid to Manchester about 2 hours. Yup! Almost 17 hours flying. But it was worth it.

I arrived to Manchester on July 27 at 12:20 p.m. and the weather surprised me with a strong rain. It may be more surprising when you live in a city were it does not rain. Then I had to go to the Manchester Metropolitan University where many of the GNOME contributors would be hosted. When the bus stopped on the Manchester Metropolitan University I went to the first building of it I see and asked how to get to the Birley Fields, our accomodations. A man told me the directions and gave me a map. After some minutes walking I got the office that assigns the rooms to the new residents. I met there Mario, a guy from GNOME who is involved in Flatpak. It was interesting to talk with him in English when at the end we realized that we both could speak in Spanish. After leaving my stuff on my room, I left the room to walk outside and I found David King. It was incredible because it was almost three years we didn’t see to each other. In that day, I also met hadess (Bastien Nocera). He helped me to get a traveler adapter. This was also the day of pre-registration in a bar called KROBAR. I got joined to the GStreamer folks who I met before in GUADEC 2014. Some of the guys came up with the idea that the GNOME logo needs a new design. I talked about it before on the #gnome-design channel. I also met ystreet00 (Matthew Waters) who helped once to create a GStreamer plugin with OpenGL.

alt text

GNOME stickers

The next day the talks started. In the venue, one of the first things I did was to buy a GNOME t-shirt. One of the talks I was very interested in was the one of Alexander Larsson about Flatpak and the one of Christian Hergert about GNOME Builder. I was very interested in the conference of hergertme because I has taken some of the ideas of GNOME Builder to apply them in Pitivi. I don’t always use this application because I am not totally adapted to it, but now I am considering to use it more instead of just coding on Gedit. That day I met Lucie Charvát, a student of the Google Summer of Code who is working in a nice feature of GNOME Builder that I always was thinking that was missing. Finally, I met to suhas2go (Suhas), other of the GSoC guys working on Pitivi like me. It was really awesome to meet him :) That day I also found Julita, who put strong effort to spread the word of GNOME in Peru. She introduced me to Rafał Lużyński who is from Krakow. It was a great coincidence because I was going to visit visit Warsaw and Krakow after GUADEC.

Davind King explaining me about GTK dialogs

David King explaining me about GTK dialogs

The second day of talks I woke up very early, about 4:00 a.m. and it was so the rest of the days. I took this as an advantage to continue with my GSoC project. One of the conferences I was most interested in was the one about Wayland, which is a project I have some interest on getting involved because it seems challenging to me and because of the EVoC. Other talk I found pretty interesting and I think I will investigate more about it was the one titled “Fantastic Layouts And Where To Find Them”. I promise to post about it as soon I try it, because you can create different layouts in GTK+ with a very simple syntax, that seems really easy to remember and understand. That day we had the party for the 20th anniversary of GNOME. I met there Federico Mena, who was telling me about how they started GNOME. It was awesome to listen to him, it was like traveling to the past and I am very grateful with the work of this man. After the event finish, I met Christian Hergert in person. I was talking with him about libpeas and GSettings. After talking with him I was convinced that Pitivi should use GSettings instead of ConfigParser.

With Federico Mena on the screens

Selfie with Federico Mena on the 20th anniversary party

The last day of the conference three Pitivi contributors (Jeff, Suhas and I) were together. I showed to Jeff a project I was working on during my vacations of the university that was a plugin for GStreamer I called gstblendersrc which I hope to continue and finish after GSoC finishes. During talks there was an open talk I was interested in that was Microsoft loves Linux. I has never supported Microsoft, but they are good in business, my interest was basically because before arriving to Manchester, during my flight from Madrid to Manchester I was reading a book named Conscious Capitalism by John Mackey (CEO of Whole Foods Market) who states that capitalism gives efficiency to non-profit organizations. By the way, I recommend the GNOME Board to read this book. Then the groupal photo took place and the lighning talks. I hope to be in Almeria the next year that is where next GUADEC will take place. Then it was the city tour, but, unfortunately, I lost the group. Anyway, it was a great opportunity to hack on Pitivi.

GUADEC 2017 t-shirt

GUADEC 2017 t-shirt

The next days were the workshops. Suhas and I were working on Pitivi. Suhas learns very fast, I think. When I did my first GSoC I had some problems. We sometimes helped between us, but that was not happening with frequency. The last day of the workshops I was looking for David King because I was thinking about working in Cheese for my thesis, but I couldn’t find him. I was with Julita and Felipe Borges. I told him about a project I have on my mind to implement in Cheese that is adding stickers over the detected faces on people. He started to give me more ideas, like to have a library of stickers fed by the community. Also he told me that it could be possible to add watermarks in Cheese so in presentations events of GNOME, people can take pictures with Cheese with the stickers and the final picture would have a watermark of even the Cheese logo or the GNOME logo. Now I need to talk about it to some professors. That was my next-to-last day in Manchester. Felipe Borges showed me some pictures of the tour he had in the Manchester United Stadium. So I went there the last day of the workshops.

I took a photo to Suhas without telling him

I took a photo to Suhas without telling him anything

alt-text

August 08, 2017

My first GUADEC :D

I attended my first GUADEC this year which was held at Manchester, UK. One of the reason I started contributing to GNOME was becasue of the family like community it has. Being a newcomer at GNOME, I felt so welcomed and part of this huge family at GUADEC!

Day 1 - My lighting talk!

The conference kicked off with amazing talks on the first day. I’d like to mention the ones which were the highlights for me :) Allan Day’s “The GNOME Way” talked about the principles we should follow at GNOME. One principle that appealed to me the most was “We take responsibility for User Experience”, it made me realize the magnitude of impact my GSoC project - Custom Effect UI for Pitivi has. Christian Hergert showed us some cool animations of Builder!

One of my favorite talks of GUADEC was Arun Raghavan’s because of its simplicty. He talked about making better the home media experience on GNOME, how we already have all the pieces required for GNOME Screencast (GNOMECast!) and that all that needs to be done now is for someone to bring the pieces together. I wonder how much skill this ‘simple’ task would require :P

I was thrilled (and nervous) to see so many people attend the intern lightning talks. I got to present my GSoC work for Pitivi. The recording of the talks will soon be made available.

Day 2 - GNOME 20th Anniversary Party!

The highlight of the second day was Jonathan’s “The History of GNOME” - “All we are doing is removing features from when we started” :D. We spent the evening celebrating the 20th Anniversary of GNOME. The insider talks with a few GNOME Oldtimers was the best part of the party. Aaaaaand, I won 1 year VPN subscription in the raffle (where is my prize though, I haven’t got it yet :D)

Day 3 - Exploring Manchester!

There was a discussion/announcement about the decision to move to GitLab. Personally, I am very excited and totally in agreement. I think it would vastly increase the developer experience and make it easier for more people to contribute.

Juan Pablo’s talk about Glade showcased it’s modern UI and how one can easily insert custom widgets in glade by writing a simple catalog file (xml).

Later, we went on a city tour exploring Manchester..

Walking tour

Meeting people

Ofcourse I met a lot of people at GUADEC! However, I’d like to mention a few -

  • Jean-François Fortin Tam (Jeff/nekohayo) - My GSoC project builds upon Jeff’s work. He appreciated my work and was so glad to see the color wheel widget :)

  • Georges Stavracas (feaneron) - When I started open source, I used to go through feaneron’s blog a lot. His journey has been inspirational. I am so happy that I got to meet him!

The Trek!

Thanks to the weather gods showing mercy on us, we went on a trek to the Peak District. Allan Day was such a wonderful guide, it was my first time trekking and it was amazing ^_^

Trek

Final Words…

I’d like to thank the GNOME Foundation for sponsoring my visit to GUADEC, the organising team for doing a wonderful job and the volunteers for helping out :) Thank you all who were at this GUADEC in making it the most awesome one yet :D See you all next year at Almería.

GNOME Foundation Sponsorship

August 05, 2017

Sailing towards Pitivi 1.0 (with some stops along the way)

With the Ken-Burns effect project completed, most of my last two weeks were spent working on some existing tasks that should be solved for Pitivi 1.0, so we can get it out sooner. Here are some things I’ve been working on:

  1. Make sure well supported audio streams are not proxyed even if they are not in a container: T7756
  2. Solved a bug where the undo stack sometimes crashed when moving the viewer: T7800
  3. Added the possibility to create custom validation checks for the advanced properties of the encoders, which will make rendering more robust in the long run: D1804

Also, Alex Balut (aka aleb) found some time to test the Ken-Burns branch and suggested some changes. Therefore, the sail towards Pitivi 1.0 had some stops, in which I spent my time working on making the Ken-Burns project a bit better. The most noticeable improvement is the fact that the displayed values of the transformation properties are now updated more often, so they are more accurate (they were sometimes completely wrong as we were not updating them when we should have).

With that said, I will continue helping with the Pitivi 1.0 release and keep you posted on the progress. Until next time!

July 20, 2017

Pitivi: Transformation properties keyframes ready to land

In my last blog post, I was telling you how my GSOC project was close to its completion. Since then, I’ve been working on getting it to a deployable state, while also adding some final touches. Now, it should be ready to land and you’ll probably see it included in Pitivi 2.0.

About the final touches: one is extending the undo/redo system so it can handle activation of transformation properties keyframes and the reset to default operation (which will deactivate the keyframes).

The other one I’ve been working on is a mechanism which allows selection of the transformation properties keyframes. Before this, the only way of navigating to a certain keyframe was using the two arrows in the transformation box.

4

Now, you can also click on a keyframe to select it and the playhead will seek to its position. This should make navigation a bit more intuitive.

So, what’s next? Having anticipated that this project wouldn’t keep me occupied for all the summer, the plan at the beginning of GSOC was to start implementing another feature: rendering only a portion of the timeline. However, after discussing with my mentor, we decided that it would be better to work on solving some existing issues in order to have Pitivi 1.0 out as soon as possible.

Until next time!

July 16, 2017

Two Realizations...

How Custom Effect Widget API evolved

Simply using the initial API, for allowing custom widgets instead of the default UI for effects, has brought in a lot of changes to it. Being new to such a task of designing the API, it was good that I had to make an example custom UI for the alpha effect. I realized that the default UI for effects does a good job (I mean, you can’t do anything more fancy than the default sometimes), except for some widgets of effect properties where something more modern can provide a better user interface for editing. This called for an improvement to the existing custom widget mechanism.

Now, custom widgets for only certain properties can be added while falling back to the auto-generated UI for the rest. To maintain consistency, one has to connect a callback to the ‘create_property_widget’ signal and return a DynamicWidget wrapper around the custom property widget. Although, I would have liked to do away with this wrapper. It seems like the best approach as it would allow the designer to truly customize the widget.

D1777 holds these new changes.

Baby steps in making custom widgets

For the past few days, I’ve been learning gtk in c and cairo. Porting the classic EggClock to gtk3 and exploring the basics. My next immediate task is to make a color wheel widget. Gtk3 already had such a widget, GtkHSV, which is now deprecated (infact, removed from the master!). Having talked on the IRC, it seems Gtk had pulled the widget from GIMP but since they found that it was not being used by other applications, they decided to deprecate it. GIMP has taken back their widget. Although, our widget would heavily borrow code, it seems building a separate Pitivi Library of custom widgets would be the best thing to do.

Subclassing a GtkDrawingArea and drawing a circle, I was trying to run a skeleton-like custom widget code, all I could see was an empty window. Took me to some to ‘realize’ my mistake (I had left the overrided realize callback empty). I was so happy when I managed to draw this circle in cairo :P

baby custom cairo

Until next time :)

Pitivi Developer Console Plugin

The first part of my project was focused in adding support for creating Python-based plugin managers in libpeas and polishing the Pitivi Plugin Manager. Initially, before the Google Summer of Code started, the Pitivi Plugin Manager was done using the PeasGtkPluginManager. However the design didn’t fit pretty well in the Pitivi Preferences Dialog, so I had to implement it again but in Python. I took as reference the GNOME Builder Preferences window. It is worth to say that I could have used libdazzle, but Pitivi doesn’t use GSettings and instead it uses ConfigParser.

alt text

The second part of my project has been to finish to implement the Developer Console Plugin. This plugin allows developers to do some quick experiments at run-time when executing Pitivi. This is very useful if you are a Pitivi developer. I have actually used it while developing the Pitivi Plugin Manager and this same plugin.

When you enable the Developer Console Plugin, a new menu item will be added to the menu.

alt text

When you click on it, a new dialog will be displayed. The plugin is based on the Gedit’s one. But new features has been added like autocompletion and shortcuts commands. Also it is integrated with Pitivi so it can show preferences in the Pitivi Preferences Dialog. Adding those preferences has allowed me to find some bugs in Pitivi due to deprecated functions and to implement new functions that are usuful to add and remove pages from the preferences dialog.

alt text

I think that one of the most challenging parts of this part of my project has been to implement the shortcuts commands. Currently, the console works redirecting stdout and stderr to a GtkTextBuffer. When you hit return key, the input command is passed eval and if it doesn’t work, then it is passed to exec. If there is an error, the error is put in the GtkTextBuffer with the error color indicated in the preferences dialog. eval and exec, both takes as argument a dictionary. An example of this dictionary may be



namespace = {
    "objA": "banana",
    "objB": "some",
    "objC": "pigs",
    "objD": "fly"
}


When this namespace is passed to eval or *exec, actually, you can use those keys “objA”, “objB”, “objC” and “objD” as variables. So you for example could do somehing simple like:


eval("print(objC + ' ' + objD)", namespace)

And you would get as output:

pigs fly

Okay, nothing complicated with that. But the thing that was a bit complicated to me was that I was adding the internal GES.Timeline object to that dictionary to have it as a shortcut command with the name “timeline”. So if the user just typed timeline in the Pitivi Developer Console plugin, he/she would access quickly to the timeline without going through app.gui.timeline_ui.ges_timeline. The problem was that when the Developer Console was loaded, the Pitivi Timeline had not loaded yet, so if you typed timeline in the console plugin you would get a None value! The same problem occured with other similar objects.

The first idea was to keep it simple and add to the namespace functions instead of variables. So there was a function _get_timeline() as a shortcut command. So the user could do something timeline = _get_timeline(). But to be honest, it was ugly. I talked to Alex about this problem and I think that he possibly had the same idea, because he asked me that the access to the Pitivi Timeline should just as simple as typing timeline. His idea was to load the console when the timeline is loaded. I had the same idea before, but the problem was that if you open a new project in Pitivi a new GES.Timeline is loaded.

I was trying to think in some hack that can lie the user about that the timeline object is actually an object and instead execute a function _get_timeline() which returns the GES.Timeline. The first idea that came to my mind was Python class properties. So I could do something like:


class Shortcuts:
    def __init__(self):
        pass

    @property
    def timeline(self):
        return app.gui.timeline_ui.ges_timeline

shortcuts = Shortcuts()

namespace = {
    "timeline": shortcuts.timeline
}

But obviously that idea wouldn’t work because as soon the developer console loads, shortcuts.timeline would evaluate to None and I was facing the same problem described above. I started to get some distraction, like play SuperTuxKary, play on the PlayStation. Then I walked around the park thinking on a solution. Then an idea came to my mind and to be honest I am not sure why it didn’t come to my mind before. The solution was to override ‘dict’. So I would create a Namespace class that inherits from dict (overriding getitem) and a Shortcuts class containing all the shortcuts commands as methods. Whenever you requested an item from the Namespace, getitem(key) would scan in Shortcuts if there is a method with that key name. If it was there, then it executed the Shortcuts class’ method. I was changing the behavior of a typical dict. The following is the code of the Namespace class and the Shortucts that I called PitiviNamespace.



class Namespace(dict):
    class ShortcutReadOnly(Exception):
        pass

    def __init__(self):
        dict.__init__(self)
        for key in self.get_shortcuts():
            dict.__setitem__(self, key, None)

    @staticmethod
    def shortcut(func):
        """Decorator to add methods or properties to the namespace."""
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            return func(*args, **kwargs)
        setattr(wrapper, "__is_shortcut", True)
        return wrapper

    def __getitem__(self, key):
        if key in self.get_shortcuts():
            return getattr(self, key)
        return dict.__getitem__(self, key)

    def __setitem__(self, key, item):
        if key in self.get_shortcuts():
            raise Namespace.ShortcutReadOnly("Not possible to override '%s', "
                                             "because shortcuts commands are"
                                             "read-only." % key)
        dict.__setitem__(self, key, item)

    def __repr__(self):
        return "<%s at %s>" % (self.__class__.__name__, hex(id(self)))

    @classmethod
    def get_shortcuts(cls):
        for attr_name in dir(cls):
            attr = getattr(cls, attr_name)
            is_shortcut = False
            if hasattr(attr, "__is_shortcut"):
                is_shortcut = getattr(attr, "__is_shortcut")
            elif isinstance(attr, property):
                if hasattr(attr.fget, "__is_shortcut"):
                    is_shortcut = getattr(attr.fget, "__is_shortcut")
            if is_shortcut:
                yield attr_name




class PitiviNamespace(Namespace):
    """A class to define public objects in the namespace."""

    def __init__(self, app):
        Namespace.__init__(self)
        self._app = app

    @property
    @Namespace.shortcut
    def app(self):
        """Gets the internal Pitivi Main Application object."""
        return self._app

    # ...
    @property
    @Namespace.shortcut
    def timeline(self):
        """Gets the internal GES.Timeline."""
        return self._app.gui.timeline_ui.timeline.ges_timeline

    # ...

    @property
    @Namespace.shortcut
    def shortcuts(self):
        """Gets the available methods in the namespace."""
        print("These are the available methods or attributes.")
        print()
        for attr in self.get_shortcuts():
            print(" - %s" % attr)
        print()

    # ...


These has been the better ideas I had for the moment. The Developer Console Plugin can be refactored using the Python’s module called “code”, althought using it doesn’t skip the problem mentioned above because this module uses eval and exec calls under-the-hood. So it also needs a dict (namespace).

When you start the console you will see the following window with a banner:

alt text

When you type shortcuts, actually this object does not exist! But you are calling to the property shortcuts, so it will executed the decorated function.

alt text

Also, you cannot override shortcuts nor the shortcuts commands (methods decorated with @Namespace.shortcut) because it will raise an exception ShortcutReadOnly wich is handled internally by the console.

alt text

And then you can access whichever of the shortcuts, like the timeline:

alt text

That’s it. I hope you enjoy this post and I hope you can soon try this plugin!

July 06, 2017

Pitivi: Keyframes for transformation properties

With a bit more than a month into the GSOC coding time, my project is almost complete. As a reminder, I was working on implementing a keyframe curve for the transformation properties (which control the positioning and size of a clip) in Pitivi.

For the last two weeks, I’ve been working on integrating the newly added keyframe curve with the undo/redo system, as well as allow values for the keyframes to be specified by dragging the viewer. I’ve also had some battles with a pretty nasty bug which made the app crash all of a sudden. Fortunately, my mentor, Thibault Saunier, took a look at it and managed to crack it, so everything should work fine now.

With my project being close to completion, I thought it would be a good idea to make an extended demo video in which I explain how the new feature works:

I’m looking forward to your feedback or any suggestions on how to make the feature better. I encourage you to keep reading my blog for further updates.

Happy coding!

June 30, 2017

A way to have Custom Effect UI - Pitivi

In my previous post, I described ‘how’ I managed to port nekohayo and thiblahute’s work towards providing an interface for adding custom widgets for effects in Pitivi. In this, I’ll tell you ‘what’ it is that I have done in my first month of Google Summer of Code.

The initial design

How Pitivi auto-generates UI for effects is interesting. For every GStreamer effect in Pitivi, a GtkGrid with the right type of widgets for its properties are packed and to manage changes to these widgets and map back the changes to the effect properties, a DynamicWidget class is created and subclassed for different type of widgets. EffectsPropertiesManager provides and caches UIs for editing effects, while GstElementSettingsWidget is a container class for configuring the effects. It is sad that such a unique infrastructure leads to a rather uniform UI.

Porting nekohayo’s branch I ended up with a light-weight plugin like architecture for having custom widgets for effects. Now, when a GstElementSettingsWidget got created it searched a particular directory to see if there is ‘create_widget’ entry point in ‘foo_effect.py’ files and saved references to this entry point. GstElementSettingsWidget’s setElement method, which previously simply called add_widgets method to generate and show the GtkGrid, was changed

  • to call the ‘create_widget’ entry point if it existed.
  • Otherwise, check if we have a custom UI availabe as a glade file.
  • If all else fails, fallback to the auto-generation.

intial API diagram

Both of these ways of having custom UI utilized the mapBuilder method of GstElementSettingsWidget to map the GStreamer element’s properties to corresponding widgets and wrapping the widgets themself with the standardized DynamicWidget API to control them.

Problems with this design -

  • This ‘forced’ us to have different files for each custom widget.
  • References to the entry points were stored as a class attribute of GstElementSettingsWidget.
  • When Pitivi does have the ‘plugins’ feature, it should somehow, if required, be able to access this custom widget API, which this didn’t allow.

The current design

The solution we came up with was to add a ‘create_widget’ signal to EffectsPropertiesManager and connect a callback which would call the corresponding create_foo_widget method for a ‘foo’ effect. An accumulator stops emission of the signal when we receive a widget, again if all else fails then we fallback to the default handler of the signal which auto-generates the UI for the effect.

current API diagram

This removed rigidity in the API, giving the option of creating custom widgets in single or multiple files, it is left up to the one creating the widget. We are no more storing reference to the create_widget methods for individual widgets. Plugins can connect to the ‘create_widget’ signal to provide enhancements.

Another possible improvement

While making an example custom UI for the ‘alpha’ filter effect I noticed that within the custom widget for the effect, the widgets for individual properties can turn out to be same as the ones auto-generated. Having this additional feature of using a single custom widget for a particular property and auto-generating everything else would prove useful in such cases.

Although the current API for custom widgets is up and running with tests, we at Pitivi want to have stable 1.0 release, as result, the current decision is that Google Summer of Code projects will not be part of this release. Feel free to ping me on #pitivi channel on freenode :) Until next time.

June 23, 2017

Enabling Python support in Libpeas

Libpeas has been for a long time one of the most used libraries to implement plugins in GNOME applications. These are applications such as Gedit, GNOME Videos, GNOME Builder and others. Libpeas' README states:

Adding support for libpeas-enabled plugins in your own application is a matter
of minutes.

However this has not been the case in Python because there is a problem. Although, currently it is possible to write Python-based plugins like many applications currently do like Gedit that has its Python Console, it is not possible to implement plugin systems for applications. The source of the problem resides in the Libpeas' function peas_extension_set_newv, that receives an array of GParameter structures. But GParameter is not instropectible! Due to this problem, there was a large discussion in bugzilla. After some discussions, Emmanuele Bassi say that GParameter should be deprecated and adding a new function with the following prototype:

  gpointer g_object_newv2 (GType gtype,
                           guint n_properties,
                           const char *names[],
                           const GValue values[]);

Some months ago, I decided to implement Emmanuele Bassi's suggestion and finally the patches were merged in master branch, and the function mentioned about was added but with the name g_object_new_with_properties. After that, the same idea could be implemented in libpeas. I have written a new function called peas_extension_set_new_with_properties and peas_engine_create_with_properties. The patch was proposed before but Garret Regier suggested to do some checking and tests. So the new patch is just pending of review and it means that it will be possible to do the following:

extension_set = Peas.ExtensionSet.new_with_properties(engine, Peas.Activatable, ["object"], [a_gobject])

I have tried this function and it works. I have a very simple example that shows how to use Libpeas in Python with this patch. I think that this function will be really useful to all the GNOME community. I think that the function internally should use g_object_new_with_properties but for the while after talking with Garrett Regier (mantainer of Libpeas), peas_extension_set_with_properties will use GParameter internally for the while.

You have a very simple example of how to implement a Plugin System using Libpeas in Python in my github repository. I hope you can soon have this functionality in master.

 

The GInterface problem

According Libpeas' README:

One of the most frustrating limitations of the Gedit plugins engine was that it
only allows extending a single class, called GeditPlugin. With libpeas, this
limitation vanishes, and the application writer is now able to provide a set of
GInterfaces the plugin writer will be able to implement as his plugin requires.

The problem is that although PyGObject allows to import interfaces from libraries written in C like Peas.Activatable, it is not possible to define new interfaces. So we will be limited to use only Peas.Activatable and thus probably extending the application by accessing directly to the GApplication.

I have been investigating the problem in PyGObject. I was reading PyGObject's source code and I got an idea of how to solve this problem. I think that the solution is to add a metaclass to GObject.GInterface and as soon as a new interface is going to be defined, a new GType and a new GInterfaceInfo should be registered. However GObject.GInterface is actually written in C. I wasn't sure, to be honest, how to do that in C, but I knew I could get to a solution by investingating. I was investigating and I knew that the solution was to add a metaclass but I couldn't find too much information about that. So I asked in Python IRC channel. According Ned Batchelder (nedbat),  I was doing "something very very esoteric", but after some discussions I had an idea. I could finally add a metaclass to GObject.GInterface, so I think I am in the right way, but I know it will take time. As this will take a very long time to complete, it does not fall under the scope of my internship. So I will not give too much importance to it after my mentor, the other Pitivi mantainers and I agree to keep it simple. So Pitivi will have only extension sets implementing just Peas.Activatable for the while.

The case of GNOME Builder

I think that a clear example of the use of GInterface to add extension points is GNOME Builder. Gedit is also a good example, but they not have many extension points as GNOME Builder do. I have been reading the source code of GNOME Builder. They define multiple interfaces:

[cfoch@localhost gnome-builder]$ find -name *-addin.c  | head -10
./libide/buildconfig/ide-buildconfig-pipeline-addin.c
./libide/editor/ide-editor-workbench-addin.c
./libide/editor/ide-editor-view-addin.c
./libide/editor/ide-editor-layout-stack-addin.c
./libide/buildsystem/ide-build-pipeline-addin.c
./libide/workbench/ide-workbench-addin.c
./libide/workbench/ide-layout-stack-addin.c
./libide/preferences/ide-preferences-addin.c
./libide/buildui/ide-build-workbench-addin.c
./libide/genesis/ide-genesis-addin.c

For example, you can see that IdeWorkbenchAddin defines the following vfuncs:

struct _IdeWorkbenchAddinInterface
{
  GTypeInterface parent;

  gchar    *(*get_id)          (IdeWorkbenchAddin      *self);
  void      (*load)            (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  void      (*unload)          (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  gboolean  (*can_open)        (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                gint                   *priority);
  void      (*open_async)      (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                IdeWorkbenchOpenFlags   flags,
                                GCancellable           *cancellable,
                                GAsyncReadyCallback     callback,
                                gpointer                user_data);
  gboolean  (*open_finish)     (IdeWorkbenchAddin      *self,
                                GAsyncResult           *result,
                                GError                **error);
  void      (*perspective_set) (IdeWorkbenchAddin      *self,
                                IdePerspective         *perspective);
};

Having an interface like this one avoids to expose everything by accessing directly from the main application. In GNOME Builder, in libide/workbench/ide-workbench.c a extension set is created so all extensions implementing this interface can do what they are ordered to do in this file by calling the methods of the IdeWorkbenchAddinInterface:

  self->addins = peas_extension_set_new (peas_engine_get_default (),
                                         IDE_TYPE_WORKBENCH_ADDIN,
                                         NULL);

For example, to set the perspective. Different plugins may have different ways to set the perspective.

  if (self->addins != NULL)
    peas_extension_set_foreach (self->addins,
                                ide_workbench_notify_perspective_set,
                                perspective);

And the plugins that implement these interfaces doesn't need to know of other types (like the application). They just care about the perspective (and other objects that can be passed as arguments to its virtual functions).

static void
ide_workbench_notify_perspective_set (PeasExtensionSet *set,
                                      PeasPluginInfo   *plugin_info,
                                      PeasExtension    *exten,
                                      gpointer          user_data)
{
  IdeWorkbenchAddin *addin = (IdeWorkbenchAddin *)exten;
  IdePerspective *perspective = user_data;

  g_assert (PEAS_IS_EXTENSION_SET (set));
  g_assert (plugin_info != NULL);
  g_assert (IDE_IS_WORKBENCH_ADDIN (addin));
  g_assert (IDE_IS_PERSPECTIVE (perspective));

  ide_workbench_addin_perspective_set (addin, perspective);
}

 

Enabling Python support in Libpeas

Libpeas has been for a long time one of the most used libraries to implement plugins in GNOME applications. These are applications such as Gedit, GNOME Videos, GNOME Builder and others. Libpeas' README states:

Adding support for libpeas-enabled plugins in your own application is a matter
of minutes.

However this has not been the case in Python because there is a problem. Although, currently it is possible to write Python-based plugins like many applications currently do like Gedit that has its Python Console, it is not possible to implement plugin systems for applications. The source of the problem resides in the Libpeas' function peas_extension_set_newv, that receives an array of GParameter structures. But GParameter is not instropectible! Due to this problem, there was a large discussion in bugzilla. After some discussions, Emmanuele Bassi say that GParameter should be deprecated and adding a new function with the following prototype:

  gpointer g_object_newv2 (GType gtype,
                           guint n_properties,
                           const char *names[],
                           const GValue values[]);

Some months ago, I decided to implement Emmanuele Bassi's suggestion and finally the patches were merged in master branch, and the function mentioned about was added but with the name g_object_new_with_properties. After that, the same idea could be implemented in libpeas. I have written a new function called peas_extension_set_new_with_properties and peas_engine_create_with_properties. The patch was proposed before but Garret Regier suggested to do some checking and tests. So the new patch is just pending of review and it means that it will be possible to do the following:

extension_set = Peas.ExtensionSet.new_with_properties(engine, Peas.Activatable, ["object"], [a_gobject])

I have tried this function and it works. I have a very simple example that shows how to use Libpeas in Python with this patch. I think that this function will be really useful to all the GNOME community. I think that the function internally should use g_object_new_with_properties but for the while after talking with Garrett Regier (mantainer of Libpeas), peas_extension_set_with_properties will use GParameter internally for the while.

You have a very simple example of how to implement a Plugin System using Libpeas in Python in my github repository. I hope you can soon have this functionality in master.

 

The GInterface problem

According Libpeas' README:

One of the most frustrating limitations of the Gedit plugins engine was that it
only allows extending a single class, called GeditPlugin. With libpeas, this
limitation vanishes, and the application writer is now able to provide a set of
GInterfaces the plugin writer will be able to implement as his plugin requires.

The problem is that although PyGObject allows to import interfaces from libraries written in C like Peas.Activatable, it is not possible to define new interfaces. So we will be limited to use only Peas.Activatable and thus probably extending the application by accessing directly to the GApplication.

I have been investigating the problem in PyGObject. I was reading PyGObject's source code and I got an idea of how to solve this problem. I think that the solution is to add a metaclass to GObject.GInterface and as soon as a new interface is going to be defined, a new GType and a new GInterfaceInfo should be registered. However GObject.GInterface is actually written in C. I wasn't sure, to be honest, how to do that in C, but I knew I could get to a solution by investingating. I was investigating and I knew that the solution was to add a metaclass but I couldn't find too much information about that. So I asked in Python IRC channel. According Ned Batchelder (nedbat),  I was doing "something very very esoteric", but after some discussions I had an idea. I could finally add a metaclass to GObject.GInterface, so I think I am in the right way, but I know it will take time. As this will take a very long time to complete, it does not fall under the scope of my internship. So I will not give too much importance to it after my mentor, the other Pitivi mantainers and I agree to keep it simple. So Pitivi will have only extension sets implementing just Peas.Activatable for the while.

The case of GNOME Builder

I think that a clear example of the use of GInterface to add extension points is GNOME Builder. Gedit is also a good example, but they not have many extension points as GNOME Builder do. I have been reading the source code of GNOME Builder. They define multiple interfaces:

[cfoch@localhost gnome-builder]$ find -name *-addin.c  | head -10
./libide/buildconfig/ide-buildconfig-pipeline-addin.c
./libide/editor/ide-editor-workbench-addin.c
./libide/editor/ide-editor-view-addin.c
./libide/editor/ide-editor-layout-stack-addin.c
./libide/buildsystem/ide-build-pipeline-addin.c
./libide/workbench/ide-workbench-addin.c
./libide/workbench/ide-layout-stack-addin.c
./libide/preferences/ide-preferences-addin.c
./libide/buildui/ide-build-workbench-addin.c
./libide/genesis/ide-genesis-addin.c

For example, you can see that IdeWorkbenchAddin defines the following vfuncs:

struct _IdeWorkbenchAddinInterface
{
  GTypeInterface parent;

  gchar    *(*get_id)          (IdeWorkbenchAddin      *self);
  void      (*load)            (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  void      (*unload)          (IdeWorkbenchAddin      *self,
                                IdeWorkbench           *workbench);
  gboolean  (*can_open)        (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                gint                   *priority);
  void      (*open_async)      (IdeWorkbenchAddin      *self,
                                IdeUri                 *uri,
                                const gchar            *content_type,
                                IdeWorkbenchOpenFlags   flags,
                                GCancellable           *cancellable,
                                GAsyncReadyCallback     callback,
                                gpointer                user_data);
  gboolean  (*open_finish)     (IdeWorkbenchAddin      *self,
                                GAsyncResult           *result,
                                GError                **error);
  void      (*perspective_set) (IdeWorkbenchAddin      *self,
                                IdePerspective         *perspective);
};

Having an interface like this one avoids to expose everything by accessing directly from the main application. In GNOME Builder, in libide/workbench/ide-workbench.c a extension set is created so all extensions implementing this interface can do what they are ordered to do in this file by calling the methods of the IdeWorkbenchAddinInterface:

  self->addins = peas_extension_set_new (peas_engine_get_default (),
                                         IDE_TYPE_WORKBENCH_ADDIN,
                                         NULL);

For example, to set the perspective. Different plugins may have different ways to set the perspective.

  if (self->addins != NULL)
    peas_extension_set_foreach (self->addins,
                                ide_workbench_notify_perspective_set,
                                perspective);

And the plugins that implement these interfaces doesn't need to know of other types (like the application). They just care about the perspective (and other objects that can be passed as arguments to its virtual functions).

static void
ide_workbench_notify_perspective_set (PeasExtensionSet *set,
                                      PeasPluginInfo   *plugin_info,
                                      PeasExtension    *exten,
                                      gpointer          user_data)
{
  IdeWorkbenchAddin *addin = (IdeWorkbenchAddin *)exten;
  IdePerspective *perspective = user_data;

  g_assert (PEAS_IS_EXTENSION_SET (set));
  g_assert (plugin_info != NULL);
  g_assert (IDE_IS_WORKBENCH_ADDIN (addin));
  g_assert (IDE_IS_PERSPECTIVE (perspective));

  ide_workbench_addin_perspective_set (addin, perspective);
}

 

June 21, 2017

Pitivi: UI for the Ken-Burns effect

It’s been three weeks since the coding period for GSOC 2017 started, so it’s time to show the world the progress I made. A short recap: I’ve been working on building a user interface which allows simulating the Ken-Burns effect and other similar effects in Pitivi. The idea is to allow adding keyframes on x, y, width, height properties of a clip, much like we are doing with other effects.

Fortunately, my mentor, Thibault Saunier, implemented this feature about 2 years ago, but a rebase of that branch was impossible, as the codebase underwent a lot of changes in the meantime. Even so, having his work as a guideline allowed me to move pretty fast. By now, I’ve implemented an interface that can be used to add and remove keyframes on transformation properties, using the transformation box to specify values at various timestamps. Here is a short demo:

What remains to be done is integrate the newly added feature with the undo/redo system, as well as allow users to specify values at various timestamps by interacting with the viewer. I encourage you to keep reading my blog for further updates. You can also check out my branch.

Until next time!

 

 

Feeds