the first installment in this
, your editor took on the task of getting video data onto his
system in digital form. Part 3
authoring DVDs with the nicely edited versions of those video clips. Now
it's time to fill in the missing second part, wherein your editor turns raw
captured video into something suitable for DVD creation.
The task to be accomplished is relatively simple: for each video clip, trim
off the extra junk at the beginning and the end. Some of them also require
internal editing; there were signs of operator error in the form of, say,
extended sequences where the sole subject matter was the floor and,
perhaps, the cinematographer's shoe. Nice transitions between the clips
were desired - a basic fade to black at the end, if nothing else. The
addition of titles is useful. And, as an added bonus, the video clips
needed to be deinterlaced before being written in a form suitable for
passing to the dvdauthor utility.
In the process, your editor encountered several tools in varying states of
readiness. He has become better acquainted than ever with the notion of
"build hell." A rather more than passing acquaintance with the behavior of
the out-of-memory killer in 2.6.24-rc kernels has also been achieved. And,
at the end, your editor believes he has a reasonable sense of the state of
the art in Linux video editing.
Avidemux is a GTK-based
editor which, according to its web page, is "designed for simple cutting,
filtering and encoding tasks." It is an interesting combination of
simplicity in some areas combined with great power and complexity in
others. It has a lot of potential, but it also has a few rough edges.
For example, Avidemux handles DVD-style MPEG2 files without trouble. But a
reader who digs far enough into the documentation (which is extensive and
useful, incidentally) finds a warning that one must exercise the "build VBR
time map" option, or audio and video will become unsynchronized in the
final product. This operation is nearly instantaneous on a five-minute
clip; given the problems which can result from not doing it, why does
Avidemux not just build this "time map" when the file is loaded? Why set a
trap like that for your users?
The actual video editing operations are quite simple. Avidemux can only
handle a single video clip, and that clip has a single set of begin/end
points. It is possible to delete from the middle of a clip using those
endpoints; deletion is instantaneous and leaves no sign on the timeline.
There is no "undo" operation, but there is an option to dump all
changes made to the file.
There is a scrollbar which enables quick movement through the clip; the
arrow keys move by single frames. In general, the interface is responsive
on your editor's machine.
One place where Avidemux excels is in its selection of video filters.
For example, your editor went looking for a filter to deinterlace the
video; he found 21 different deinterlacing filters. Many of these filters
have an extensive set of configuration options. Actually choosing the
right filter and options for the task at hand is an intimidating task, and
the documentation does not provide a whole lot of guidance. In the end,
Your editor got reasonable results with the "yadif" filter, as can be seen
in the "before" and "after" images on the left.
A fade-to-black ending was achieved with another filter. It works
beautifully, if one does not mind that (1) there is no choice of what
to fade to beyond a "fade to black" toggle, (2) the portion of
the clip to be affected must be identified by typing in frame numbers, and
(3) those frame numbers are not adjusted should somebody, say, delete
some video from an earlier part in the clip. The capability is there, but
the interface needs some work.
Other filters allow cropping, mirroring, color modifications, noise
removal, sharpening, blurring, addition of subtitles, the addition of logos
from image files, the creation of animated DVD menus, etc. Should all of
those be inadequate, the "swiss army knife" filter is there for more
general low-level processing. There is also a scripting interface for
Avidemux, though your editor did not attempt to make use of it.
The interface allows the user to view the video either before or after the
filters have been applied - or both together. The latter mode, though,
tends to run slowly, though the post-filter output, by itself, worked just
In the end, saving the file out as a DVD "video object" does the job -
though one has to assume that the rather spartan "save" dialog will do
that. Like most (but not all) video editors, Avidemux does not actually
change the video data until told to render a new file. The list of edits,
filters, etc. can be saved as a "project" file (an Avidemux script, really)
so an editing session can be resumed at a future point using the original
The bottom line is that Avidemux is a capable and reasonably solid tool -
your editor was not able to make it crash. Its long list of filters will
be appealing to some users. Its inability to work with more than one clip
at a time will rule it out for many others, though. Like so many other
tools in this category, it's almost there.
The Cinelerra tool has an interesting history. It was once known as
"Broadcast 2000," before being withdrawn because somebody was worried about
legal liability. Now it is available as "Cinelerra," but in two versions.
version is published by a company named Heroine Warrior, which has no
real interest in the hassles of dealing with a community or making regular
releases. Heroine Warrior is, however, generous enough to make the code
available under the GPL; a group of developers has taken the code and made
Cinelerra CV - the "community
version." This version is supposed to be under active development and move
more quickly, but it still doesn't seem to be moving all that fast,
There are some good documents for Cinelerra, but, reading them, one starts
to encounter certain themes. For example:
Cinelerra is not perfect. Before long you will be familiar with
the tendency it has to crash
Quicktime is not the standard for UNIX but we use it because it's
well documented. All of the Quicktime movies on the internet are
compressed. Cinelerra doesn't support most compressed Quicktime
movies but does support some. If it crashes when loading a
Quicktime movie, that means the format probably wasn't supported.
Cinelerra is by far the most complex - and capable - of the tools available
for Linux. If you are looking for an editor designed for the creation of
complicated video with lots of effects, Cinelerra is the tool for you.
Unfortunately, Cinelerra does not appear to have a development community
which is up to the maintenance of a tool of this size. So it is difficult
to work with and not particularly robust.
At startup, Cinelerra puts up four individual windows. The "timeline"
shows all of the tracks being edited, and is the place where much work
actually gets done. There are two video windows; one displays the current
state of the timeline, while the other can be used to look at individual
clips outside of the timeline. Then the "resources" window holds
The timeline display is quite nice. Video thumbnails along the line give a
rough sense of what is happening in each clip. The display of audio levels
is also highly useful when one is trying to find specific events; it would
be nice if other tools picked up this idea. A number
of editing operations can be performed directly on the timeline; each
track, for example, has a horizontal line which can be manipulated to
adjust the (audio or video) levels at any given point. So a fade-to-black,
for example, is a simple matter of ramping the video level down at the
For more complex operations, there is a large list of effects which can be
applied. These effects show up on the timeline next to the tracks they
operate on; their end points can easily be dragged around. Cinelerra will
attempt to render effects when the timeline is being played, but that tends
to slow the program (not the fastest tool to begin with) to a point where
it cannot keep up with normal video rates.
Cinelerra does not modify any data until told to render the project. It
cannot create DVD video objects directly; one must render audio and video
separately, then multiplex them outside of the program. The edit list can
be saved separately.
There is a whole host of features in Cinelerra not found anywhere else.
For example, it can be used to drive a rendering farm for those big
production jobs. There is a motion tracking subsystem built into it
("The intricacies of motion tracking are enough to sustain entire
companies and build careers around"). There's a set of options
for audio and video capture. And so on.
But your editor could never get all that far with Cinelerra before it ran
the system out of memory. One does, indeed, become familiar with its
tendency to crash, but it's especially annoying when it takes the rest of
the system down with it. Cinelerra should really be one of the star
applications in the free software world. It has a great deal of power and
can do amazing things; it could be a professional-quality tool. What it
needs is for the community to truly take
charge of the "community version" and turn it into a system which is fast,
robust, and easier to use. To that end, it would help if the two people on
the planet who can succeed in actually building this system would clean up
that process and, in general, make Cinelerra more welcoming to new
developers. The foundation for a great video editor is here, but there is
a lot of finishing work to be done.
Kdenlive is a KDE-based editor under
active development; version 0.5 was released in August, 2007. Having not
found a version for Rawhide, your editor set out to build this tool, only
to give up in despair. So, as an aside, your editor would like to offer a
helpful suggestion to developers who want people to actually use their
code: if you absolutely must use your own build tool instead of
make, and there is just no alternative to using a tool which
nobody has heard of or packages and which does not have a web site or
working download location, please consider just packaging said tool with
your code. Your editor is sure that "unsermake" is vastly superior to the
alternatives which we all have on our systems already, but it doesn't help
if you can't find it.
Of course, even after solving that problem, your editor was not able to
build this tool. Fortunately, Ubuntu ships it, so that is the version
which was used here.
The initial Kdenlive experience is a little rough; it asks for a set of
default parameters. How is one to choose between, say, "CIF NTSC" or "DV
NTSC" or "DV NTSC Widescreen"? There is no help on offer to guide the user
toward the right choice. Once past that, the user sees a window with three
major panes which offer functionality similar to that available from
The first step is to bring one or more video clips into the "project tree,"
which is (usually) visible in the upper left pane. These clips can be
viewed in the "clip monitor" on the right. A clip of interest can then be
dragged down to the timeline area, where it can be easily positioned
relative to any others which are already there.
Kdenlive uses the "divide and conquer" editing method. To remove a section
of a clip, the user positions to one end of that section, then selects
"razor" to split the clip in two at that point. Another split at the other
end isolates the section to be removed, which can then be deleted with a
separate operation. There is (with the exception of transitions) no way to
apply an operation to a part of a clip - the area of interest must always
be razored out first.
As a result, the fade-to-black effect is not quite as easily achieved in
Kdenlive as with some other tools. There is a "brightness" effect, but it
changes the brightness to a constant value through the entire clip. The
way to fade out a scene is to add a new clip with a solid color (easily
done in Kdenlive), then use a crossfade transition to join the two clips
Transitions are added by selecting the first track and, via the
right-button menu, selecting the desired transition. Various parameters
(such as the time required for the transition) can then be tweaked. It all
works easily; Kdenlive is a fun tool for quickly piecing together different
bits of video into a coherent whole.
There are separate video windows for displaying individual clips and the
timeline as a whole; by default, they cannot both be viewed at the same
time. Playback is responsive. It's a little more awkward than with some
tools, though: the position cursor is small and hard to grab, and there is
a shortage of keyboard shortcuts for moving around. The timeline is less
informative and less functional than Cinelerra's, but the information one
really needs is there.
When the project is done, there is a nice "export to DVD" option there to
do the rest of the work. Kdenlive can create the video object files and
fire up Qdvdauthor to do the rest, or it can create a
basic, single-title DVD internally and (using k3b) burn it to a disc. Your
editor, thus, should have
mentioned Kdenlive in the DVD authoring article, but he was unaware of this
feature at that time. It all works easily; your editor was able to make a
playable DVD with minimal trouble.
It was not the most beautiful DVD, though, because Kdenlive has no
deinterlacing capability. Those of us unlucky enough to be starting with
interlaced video must handle that operation separately, before or after the
While any of the editors discussed here could conceivably work with
high-definition video, Kdenlive is the only one which appears to have been
written with that in mind. Projects can be set up in HD formats without
undue tweaking. Your editor was not in a position to test this capability,
All told, Kdenlive comes across as one of the most finished of the free
editing tools. It is relatively straightforward to use and it has all of
the features that most people are likely to need. For many applications,
this could well be the first tool to reach for.
Despite its "K" name, Kino is a GTK-based
video editor. It is quick and easy to use, but also lacking somewhat in
Kino only works with a single video format - the digital video (DV) format
associated with contemporary camcorders. When started with something else
(say, your editor's MPEG files from the capture card), it will offer to
convert the file into DV. This process works, but the result is a
significant (5-10x) increase in the size of the file.
There is no timeline in Kino; instead, it has a "storyboard" in the
leftmost pane. Each video clip becomes a separate scene in the storyboard,
with each being played strictly before the one after it. Like Kdenlive,
Kino works by dividing clips and applying operations to the pieces. So
trimming video is done by "splitting" the scene into wanted and unwanted
parts, then deleting the latter. The documents make much of the "powerful"
three-point trim feature, but your editor doesn't get it; it just seems
like a way to set the beginning and ending split points on the same screen,
but the amount of work remains the same.
Moving within clips is quick and easy in Kino. There is also a
scrollbar-based "jog wheel" for variable-speed motion in either direction.
What your editor really likes, though, are the keyboard shortcuts,
including vi-style bindings for moving, frame-by-frame, through the
material. It makes finding the exact spot to make a cut a quick affair.
Kino offers a reasonable set of effects, though the interface and
implementation are awkward. Most effects apply to a full scene, so the
normal mode of operation is to split scenes where an effect is to be
placed. There is an option to "limit" an effect to a period of time at the
beginning or end of a scene, though, so something like fade-to-black or a
crossfade can be done without making new scenes.
Or so one would think. Unlike most other editors, Kino does not apply
effects at playback time; instead, an effect must be rendered when it is
applied to the scene. The result is a new scene (even if the limit option
described above is used) which contains the result of a new DV file created
by the effect renderer. For good measure, the rendering code places the
rendered file (with a name like 001.kinofx.dv) in the user's home
directory, which can quickly become cluttered with them. This approach
lets Kino display effects without performance problems, but it is a bit
messy and inelegant.
While Kino only works with DV files, it has one of the nicest export
dialogs around. There is a long list of options, one of which is DVD-style
MPEG. There's even a "deinterlace" pulldown with a few options. The
internal deinterlacer is, as advertised in the menu, very fast, but the
results are not all that great. If one, instead, has Kino use the external
YUV deinterlacer, things will be exceedingly slow, but the results are
worth it. Examples from both deinterlacers can be seen on the left.
By default, the DVD exporter creates the necessary video object file and a
simple dvdauthor script for a minimal DVD. There are options, though, to
burn the DVD immediately or to go into Qdvdauthor for further work.
One might mention here that, like most of the other tools discussed here,
Kino does not play nicely with others when it comes to the audio
subsystem. Each tool has its own way of responding to contention, though.
In this case, if Kino is unable to get exclusive access to the audio
device, it shows its displeasure by playing video (silently, of course) at
ten times the normal speed. After a while one learns to recognize this
particular tantrum, but it still would be nicer if the application would
say something like "I'm not willing to share the audio device, can you
please stop your music player if you want to play back your video?"
Bottom line: Kino is a reasonably capable editor which, after a very short
learning period, is quick and fun to use. It may well be the best option
for people with relatively simple needs. Those wanting more sophisticated
capabilities, though, are likely to see it as an underpowered toy.
The Linux Video Editing System
(LiVES) is a relatively simple editor with some interesting capabilities.
The web page claims:
LiVES is good enough to be used as a VJ tool for professional
performances, and as a video editor is capable of creating dazzling
clips in a wide variety of formats.
Your editor, however, is not a VJ. So his experience with this tool was
not the best.
The process of importing a video clip into LiVES is slow and
disk-intensive. After some investigation, your editor figured out why:
LiVES works by converting every video frame into a separate JPEG image
file. The end result is a directory containing tens of thousands of images
and a massive expansion in the size of the clip. It also cannot be good
for system performance in general; your editor can only suggest that using
a filesystem with indexed directories would be a good idea.
LiVES is one of those applications with such a sense of its own importance
that it comes up maximized from the outset. The interface reconfigures
itself on the fly depending on what operations are selected - in
particular, video display windows come and go in a frequent and distracting
manner. The default directory for video files in /usr/local.
Cross-fading one clip into another works, but it loses the
synchronization with the audio. Many tasks are done by running external
programs; should that program fail, LiVES will tell the user, but it does
not pass on the information provided by that program. So figuring out
why things fail is a matter of digging through debug and
Somewhere in this process, your editor decided that, while LiVES may indeed
make VJs happy, it is not a serious editing tool for the rest of us. There
is the potential for some nice features there, but this application needs a
lot of work before it will be ready for general use.
One gets used to thinking of video editors as being huge programs written
in relatively fast languages. PiTiVi, however, is an
exception to the rule: it's a smallish application written in Python. Of
course, it's only small when one overlooks some of the external pieces -
This application, too, was a bit of a challenge to get going. It has
various dependencies not accounted for in its configure script, including
some strange ones: why does a video editor need to import Zope modules?
Still, your editor had better luck here than with some of the alternatives.
The good news is that, despite its Python implementation, PiTiVi is
responsive when moving around in video clips. On the other hand, moving
around in clips is really about all that PiTiVi can do at this point.
There is a rudimentary timeline display which does not do anything, and no
editing options are available. So PiTiVi, while being a promising start,
is not really an editor at this time.
Worth mentioning in passing: the Open Movie
Editor looks like a tool with some promise. It disliked your editor's
video files, though, claiming that it only supports files with a 25
frames/second rate. Your editor, deep in NTSC country, has no such files.
Hopefully, as this project matures, it will achieve the generality this
kind of tool must have.
The free software community can be aggravating sometimes. We clearly have
the ability and the desire to create top-quality tools for tasks like video
editing. But what we get is a half dozen tools, none of which is a
complete solution to the problem. Your editor would be the first to say
that competition between projects can be a good thing, inspiring everybody
involved to push harder and achieve more. But, still, maybe having fewer
competing tools might just help people to work together and make tools
which are truly great.
That said, the state of the art in Linux video editing is not as bad as one
might think. The tools are there to put together a decent video without a
great deal of trouble. As mentioned above, Kdenlive is arguably the most
polished of these tools, with Kino also being a good candidate for simpler
applications. And Cinelerra remains in its position as the application
that is going to be truly spectacular, once all of those loose ends finally
get tied up.
Your editor once heard Lawrence Lessig say that text is like Latin for
younger people today, and that video is the preferred way to communicate.
If that is true, then we want to make it possible to communicate as richly
as possible while using free tools. We have a good base to build on, and
many smart people have solved many of the hardest problems. Finishing the
job is well within our capabilities.
to post comments)