Sunday, November 8, 2015

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
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:
 or a psy-tune:
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.

Tuesday, October 20, 2015

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”.

Thursday, October 15, 2015

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.

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!