June 10, 2009
This article was contributed by Nathan Willis
Video editing stands to get significantly easier for Linux users this
year. The GStreamer-based
nonlinear video editor (NLE) PiTiVi
has released its first public build since undergoing a substantial rewrite.
Version 0.13.1 was released
May 27, 2009, and adds a handful of user-visible changes but makes
substantial improvements under the hood, laying down groundwork for the
next development cycle.
Video editing continues to be an unsettled topic among Linux
users. Among the handful of applications currently available, each has its
share of limitations, user interface quirks, and stability problems. Kino,
for example, is very capable at capturing DV video from cameras, but uses
an unfamiliar UI for an NLE, without the familiar editing timeline, and
requiring a rendering step for every title, transition, or effect.
Kdenlive and Cinelerra offer broader feature sets, but are plagued by
widely-reported installation and stability problems. For its part, the
chief criticism of PiTiVi has always been missing functionality. The
rewrite of the 0.13 series, begun in 2008, promises to change that.
PiTiVi (pronounced "P-T-V") uses Python for its user interface and
top-level logic, but all audio and video processing — from playback
to filters — takes place in GStreamer. That gives the application
better performance, the ability to take advantage of GStreamer's
multi-threading, and independence of codec and file formats. Any format
supported by GStreamer is supported by PiTiVi, which is convenient for
users, and distributions can include the application without introducing a
package dependency on potentially legally-risky media engines such as FFmpeg. GStreamer's plugin-based abstraction
allows PiTiVi to function regardless of whether any particular codec pack
— patented, commercial, proprietary, or free — is
installed, and does not require maintaining a specially-tailored playback
engine to avoid legal conflicts.
Users will notice that PiTiVi 0.13.1 supports multiple layers in the
timeline, permitting simple overlay of multiple video and audio sources,
support for still images as video tracks, and the ability to trim audio and
video clips in the editor. As the before (at left) and after (below, at
right) screenshots depict,
audio waveforms and video thumbnails are now used to represent tracks in
the timeline, making it easier to distinguish between clips while editing.
In addition to the visible changes, however, the more substantial work of
the 0.13.x series is the refactoring of the core, which will eventually
make the editor more powerful.
Refactoring
Lead developer Edward Hervey said that the refactored application
core reflects several years of feedback from users and discussions with
professional video editors. "The previous design was more the
evolution of a certain view I had of video editing and its workflow back in
2003." The old design included a lot of hard-coded features that
held the application back in real-world workflows, such as limits on the
number of audio and video tracks, a limit on the number of layers, and only
being able to have one project open at a time.
One example Hervey cites is the internal representation of the editing
timeline. The old PiTiVi core was tied directly to the timeline provided
by the Gnonlin library (a
dependency of PiTiVi that implements NLE features as GStreamer plugins),
which limited it to one object per stream and track. The new core adds an
intermediary
layer, permitting multiple objects and tracks.
The rewrite is also considerably more modular, making it easier for the
developers to add additional features. Features planned for the 0.13.x
cycle include critical editing tasks like titling, transitions, and effects
— operations which are already possible in GStreamer
plugins. Hervey explained:
There are two titling elements for example (takes text in
input, renders it with Cairo/Pango into a video frame and outputs that
frame), we have a video mixer elements (to
combine several streams), several elements to apply alpha/transparency to a
video stream, some video effects (from
EffecTV) [...] But despite
having all those elements, there is some work to be
done in PiTiVi to make them useful to end-users. Classifying the various
effects/operations is one such task we have to do (there's no big
difference GStreamer-wise between color balance, video mixing or applying a
funky video effect). We also need to show the
various properties of those effects in an editing-oriented way, sometimes
add some UI to properly modify those properties (Using a bluescreen effect
would require having a dialog box with a color picker and a
previewer).
Most of the user
interface work has been taken on by new team addition Brandon Lewis,
with assistance from Jean-Francois Tam. As is often the case, the team is
trying to maintain a clean separation between the application core and its
user interface, but for PiTiVi this choice has implications for its
customizability. Hervey explained that the goal is to keep the UI as
simple as possible in order to make the program usable by novices, but to
leave room for building additional functionality on top of it through the
use of plugins.
GStreamer
PiTiVi development is intrinsically tied to GStreamer development. As
Hervey explained in an interview with
Gnomedesktop.org, he, Lewis, and core developer Alessandro Decina are all
employed by Collabora Multimedia,
which sponsors ongoing GStreamer work alongside other open source projects.
Some of Collabora's revenue comes from consulting jobs that involve
building custom GStreamer processing and editing solutions, so building a
dependable NLE is an important task, which influences the direction in which
GStreamer itself moves.
One such influence was the notion of "segments"
that was added in GStreamer 0.10. Segments allow PiTiVi to track in- and
out-markers for each video and audio buffer without altering the buffer
itself, greatly speeding up the process of rearranging clips in the
timeline. "Previously in order to do time-shifting we'd have to
modify the timestamps of all buffers, whereas with segments we can give
information as to when buffers that follow that event will be displayed, at
what speed, etc..." In addition, Hervey added, PiTiVi development
tests all GStreamer plugins to ensure that they fully conform to the API,
such as making sure that all decoders can do sample-accurate
decoding.
Furthermore, as with any GStreamer project, the modular nature of the
media framework means that other projects can share in the improvements
that originate in PiTiVi, and vice-versa. Because PiTiVi represents a
different usage of GStreamer than the considerably more common "media
player" paradigm, it stress-tests plugins in different ways.
Up next on PiTiVi
The next milestone in PiTiVi development is scheduled to be released in
July, adding essential features like undo/redo, blending and compositing,
and video capture. Because it is officially designated a development
branch, the team has not pushed the 0.13.x series for inclusion in Linux
distributions. Until then, users interested in testing the development
releases can either download
and compile source code packages, or if using Debian or Ubuntu, access
development binaries through the project's Personal Package Archive (PPA).
The PPA includes updated packages for GStreamer, GStreamer plugins,
Gnonlin, and other key dependencies. Building from source also requires
satisfying these dependencies, so instructions are
provided on the PiTiVi wiki.
NLEs are notoriously complex beasts, and a stable, capable NLE remains a
missing piece of the free software desktop for many users. Because it can
leverage GStreamer for the heavy lifting of media processing, PiTiVi stands
a better chance than most young projects of reaching dependable usability,
and if the first release of the newly-rewritten core in 0.13.1 is any
indication, the application is well on its way.
(
Log in to post comments)