The Grumpy Editor's video journey part 2: Video editors

In the first installment in this series, your editor took on the task of getting video data onto his system in digital form. Part 3 talked about 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

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.

Before
After

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

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

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.

Cinelerra

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. The "official" 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, unfortunately.

There are some good documents for Cinelerra, but, reading them, one starts to encounter certain themes. For example:

Or this one:

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 everything else.

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 right place.

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

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

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

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 editing process.

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, though.

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.

Kino

Despite its "K" name, Kino is a GTK-based video editor. It is quick and easy to use, but also lacking somewhat in power.

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.

Internal
External

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.

LiVES

The Linux Video Editing System (LiVES) is a relatively simple editor with some interesting capabilities. The web page claims:

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 strace output.

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.

PiTiVi

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 - like gstreamer.

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.

Conclusion

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.

---

(Log in to post comments)

I'm not sure about your build problems with kdenlive. I just run:

make -f admin/Makefile.common
%configure --with-qt-dir=/usr/lib/qt-3.3
make -j1

I have a fedora spec for it and it's dependencies to use, if you so desire:
ftp://ftp.blagblagblag.org/pub/BLAG/linux/70000/en/os/i38...

-Jeff

Kino + Cinelerra is probably the best way to go. Use kino to capture the video from DV, and
export the final product. Use cinelerra to edit. In my experience, cinelerra is designed to
crash (i.e. it crashes quite a lot, but it good at recovering once it has done so),
nevertheless, you should frequently save your project under different filenames. Also,
cinelerra requires at least 2GB of RAM, and will appreciate it if you have 2 screens, and if
you can give it access to directories on 2 physical disks (one source, one for rendering to). 

That said, the best tool I ever used was Pinnacle's Studio DV, under WinXP. 

Another capture option from a DV camera is of course dvgrab.  That's all I've ever used and
it's worked fine for me.  Being a command line program though I realise it's not everyone's
cup of tea.

Given the entertaining comments about the OOM killer kicking in with these video editors, it
would be useful to know some details such as amount of RAM in the test PC, size of video
images being edited at the time, and maybe whether some apps were more prone to being OOM
killed.

Also, isn't it possible to simply increase swap size (and turn off the relevant memory
overcommit sysctl) to ensure the OOM killer doesn't cause problems with video editing, as per
http://lwn.net/Articles/104179/ ?  If so, some pointers on this would be useful.  

Finally - are any of these apps multi-threaded to make use of multi-core CPUs?

On a 32-bit system, no single app can use more than 2GB of RAM (if I understand correctly). So
3GB won't help very much. This is a particular pain, because even when running a
memory-monitor on the taskbar, you can't easily see whether one particular app is about to run
out of addressable RAM. 

That's why my new desktop machine is 64-bit, so that firefox can address almost 8GB of real
RAM, and furthermore, leak into 16GB of swap, before it finally crashes!

On 32-bit x86 Linux systems with a standard libc the largest chunk of contiguous memory
available to any process is ~2GB; there are some dribs and drabs (about another half-GB)
available after that.

This has to do with how libc aligns its ELF segments relative to the heap.

On PAE enabled systems one can have multiple different processes each with their own 2+GB of
allocated memory.

Interestingly I've heard that 32-bit processes running under a 64-bit kernel can get much
closer to 3GB contiguously allocated.  I guess the kernel is able to stay completely out of
the way in that case.

Unfortunately I haven't found any really good URLs that describe this in sufficient detail
(with sufficiently comprehensible diagrams) that I can really recommend them.  And my
comprehension is limited --- so I can't explain it better nor draw the diagrams that I'm
eventually hoping to find.

(It's unfortunate because I work at a company that makes EDA software --- which is notoriously
memory hungry.  So the question comes up far too often, despite the accelerating adoption of
64-bit systems).
JimD

unsermake was the tool which was intended to replace automake back in the 
KDE 3.4 days. It never really got off the ground and was happily discarded 
and replaced with cmake. KDE 3.4 and 3.5 can use it, but don't *need* it. 
I'm rather disconcerted to find anything requiring it at all...

I'm 99% sure that what happened is that the kdenlive developers use 
unsermake themselves, and forgot to re-run make -f Makefile.cvs when 
making the distribution tarball for release.

The files generated for unsermake are not compatible with automake.  The 
choice of unsermake and automake happens before the configure script is 
created in the KDE 3 build system (when running make -f Makefile.cvs, 
which is the same as make -f admin/Makefile.common cvs).

Ah, right, that explains why I never needed unsermake: I've always got 
everything from svn and Makefile.cvsed it.

Here's few random comments from someone who has used Cinelerra for numerous DVD projects over
the past few years.

Firstly, I'm not sure why there's an emphasis on deinterlacing in the context of making a DVD.
While deinterlacing will make the clips and the resulting video look better when played back
on a non-interlaced monitor (which usually means on a computer via software which does not do
decent realtime software deinterlacing) it will actually make the resulting DVD look *worse*
when played back on a normal interlaced TV.  The only exception to this is if the field order
gets changed between the raw video and the final DVD MPEG2 stream - then the DVD will look
absolutely terrible.  One could fill a book with the details of field order, interlacing, when
to use it, how to get it right, etc etc - it's a complex subject which only gets worse in NTSC
land.  The upshot though is that you only want to deinterlace material which will be viewed on
a computer; for DVDs destined for a normal TV you want to preserve interlacing (and field
order).

As to cinelerra being a memory hog, I can confirm that this is the case.  However, the extent
that this was encountered by the author is not consistent with my experience.  Admittedly I
use the HV (Heroine Virtual) cinelerra, not the CV version seemingly used by the author, so
perhaps there are memory issues in the CV version which are not in the HV version.  Even so, I
can confidently say that in 5+ years of using cinelerra for projects up to 6 hours long with
individual clips lasting 90 minutes I have never once had Cinelerra HV cause the OOM killer to
act.  This is on a very lowly 866 MHz Pentium3 with only 512 MB of RAM and minimal use of swap
(in the past it's been even slower with less RAM).

Cinelerra does have a propensity to crash for no apparent reason though.  "Save often" is
definitely good advice.  It's interface is also somewhat unusual and takes some getting used
to.  Once you know how to drive it you can do incredible things, but the learning curve is
unnecessarily steep which is unfortunate.  In this day and age there are certainly more
intuitive GUI interface concepts/nomenclatures for achieving the same things.

This is certainly not to bash cinelerra.  I think the authors (both HV and CV) have done an
incredible job on getting this complex tool to the point where it's at today.  It's a tool
which does allow me to complete the projects I'm working on to a standard I simply couldn't do
with any of the other FOSS NLEs in existance today and for this I am very grateful.  Having
said that, the developers behind the CV version are aware of the need to work on stability and
the GUI (there has been recent discussings about this on the CV mailing list).  As stated in
the article though it does seem that the developer pool is rather thin and as a result any
significant work on cinelerra-cv (and the HV version for that matter) does take an inordinate
length of time.

I should also note that I use cinelerra only for the video portion of my projects.  For the
audio side of things (which invariably involves multitrack sources and mixdown) I utilise
ardour.

As a parting comment, I agree totally with the general conclusions reached in this article -
we have some promising FOSS video tools but they all need varying amounts of work before they
are ready for the masses.  They can be used now to do "real work", but only if one is willing
to put up with the often considerable rough edges.

In principle, the parent comment is correct about interlacing, but it's not apparent to me
that it's necessarily desirable now in 2008

A "normal" interlaced TV was the only thing in people's homes in the 1990s when DVD was
introduced. However most of the material people are actually watching on DVD, that is, movies
and high budget TV productions was shot on film (or a film-like digital process), and so no
true interlaced source exists. As a result what's actually on the DVD is essentially 24 fps
progressive scan, and the interlacing is created during playback.

[ It's possible to use the same telecine process an analog TV channel uses to broadcast a
movie, and then record the interlaced result on DVD, and in a few famous cases this has
actually been done to movies you've heard of, e.g. some releases of The Princess Bride, but
it's acknowledged that this is the Wrong Thing™ ]

In another decade, with CRTs gone from most people's homes, interlaced video may be solely a
legacy format. At that point approaches your choice for old home videos, where the source
material really is interlaced will be between relying on a realtime de-interlacing filter in
your DVD playback hardware or television, and doing it once with high quality software as our
Grumpy Editor elected to.

I agree that the move away from "traditional" TV devices, video interfaces and delivery
methods in favour of non-interlaced and computer-based options is slowly making interlaced
video a legacy format.  I also suspect that the speed at which interlaced formats become
deprecated will be different in almost every country.

Having said that, a vast majority of people I provide video to are still running AV equipment
which relies on standard PAL interconnects - and that means interlaced video.  For such
people, providing a deinterlaced 25 fps program (25p) will result in an obvious drop in
quality compared to 25i (and is in fact a lossy operation if starting with 25i source
material).  Obviously everyone's situation is different, but in this case 25i is a format
which provides the best result for everyone: those with 25i equipment get the best result they
can hope for, and those with gear capable of 50p will still get an acceptable picture due to
deinterlacers in their players/tvs (which aren't all that bad even now).  Note that
distributing with 50p isn't really an option yet since few people have players capable of
dealing with this format (DVD doesn't).

While the above refers (obviously) to PAL land, similar statements apply to NTSC.

It should also be noted that in our editor's case (as in mine), the source material was almost
certainly interlaced, so his deinterlacing operation from 30i to 30p was in fact lossy.

This whole area is a minefield and looks set to remain that way for some time to come.
Ideally interlacing would just go away, but there's a huge installed base of interlaced
equipment which guarantees that this will be a long drawn out process.  Until that process
completes one has to be aware of all the issues and make a call based on their particular
circumstances.

Almost all current HD broadcasts are interlaced too ("1080i"), and will be for some time :-(.
AFAIU the reason they do this is that for most shows it's actually considered superior to the
equivalent progressive format ("720p"), because at a given bit-rate, interlaced video gives
better spatial resolution at the cost of some temporal resolution.  Maybe.  Something like
that.

Looking forward to ubiquitous 1080p, myself.  (At last, something to use those terabyte drives
for!)

For adding English subtitles to an Hungarian movie. Naturally to translate the phrase meaning
"Can you direct me to the station?" with the appropriate "Please fondle my bum."

my hovercraft is full of eels

jake

I did subtitles in Linux for a client that wanted english subs for a movie we made; I used a
few different programs. Gnome-subtitles wasn't good at that time, however, it seems like it is
capable now.

So you might want to try it out. http://gnome-subtitles.sourceforge.net/

Wow, it's big! On my system, which has GNOME already installed:
# apt-get install gnome-subtitles
After this operation, 54.8MB of additional disk space will be used.

In its latest Version, Open Move Editor supports different Framerates.

You might be interested in this review of Open Movie Editor to complete your set! 

http://stream0.org/2008/01/open-movie-editor-surprisingly...

Thanks for the article.
I use by preference cinelerra/kino and kdenlive. Out of this i wanted to share my experience
and comments as well.

The crashing of my cinelerra (CV version compiled from source on a ubuntu 64 bit and 32 bit
platform) is no problem (I had it only some 5 times; i am using cinelerra for about 6 months).
I think this crashing critic is sometimes overdone. 
Worth to say about cinelerra is the very extended manual. 
I hope that cinelerra will improve on capturing. I use kino for capturing instead. 
I admit the steep learing curve but it is worth to do. Some critics is the result of not
having spent enough time to learn cinelerra.

Kino is working well. I have read that development stopped besides bug fixing because the
effort to convert kino to multitrack is big. One of the devs is now in the kdenlive project.

Kdenlive is working fine as well. It is clear that kdenlive is still under heavy development.
It already has a lot of useful features. I have met some bugs but found workarounds (picture
in picture sizing; titling). It is a very promising application.

I have tried other applications (Lives, Pitivi) but left them because I did not like the gui
(pure personal appreciation) and because they were earlier in development than
kdenlive/cinelerra.

Blender is the next one I will explore.
 

I agree.  I've been playing with Cinelerra a lot lately, using a number of effects, and it
hasn't crashed on me yet.  I think the interface is also pretty reasonable once you get used
to it.  And it can do some amazing stuff.  I am using the latest version for Ubuntu Gutsy, in
a third party repo.  (Last time I played a lot with it a couple years ago, it *did* have a
tendency to crash.)

I was starting to entertain the idea of getting an iMac and Final Cut Pro for video editing.
No more -- I am completely convinced that Cinelerra will meet my needs.

Some people are getting together to work on "Cinelerra3", currently just a code name, that
will be a complete rewrite.  Looks like they are making progress, though perhaps not at the
highest speed.  It also looks like they're trying to be completely open and make things easy
for new developers.  I'm thinking of getting involved myself.
http://www.pipapo.org/pipawiki/Cinelerra3

Just thought I would thank our favorite editor for his work on this article.  And for the
feedback comments as I feel it helped me on my first movie project.

I was most familiar with kino as I have used it for the last several months getting our home
movies off our Sony miniDV camera.

I did evaluate some of the mentioned software in the article and the comments.

Kdenlive:  Just never got it to work on my Gentoo system.  I built three versions and didn't
have success with any of them.  Version 0.4 that is in portage never would load any of my
video I had captured.  The other versions 0.5 and a SVN just crashed on start-up.  Obviously
something on my system was not right and I didn't invest the time to find out.

Open Movie Editor behaved just like our editor, just didn't like any of my video.

I ended up using kino to capture raw video from the miniDV and to make specific cuts that I
wanted.  Used some of their FX too.  Since I was new to making a movie I was not up to doing
too many effects.

I used Audacity to play with the audio and mix different audio together.  Overall this was
easy to do but I did have some local audio issues as it didn't seem to mix well with other
software that was using /dev/dsp.  This again is probably my own fault not having things setup
right.  The point being that Audacity works sufficiently.

I used cinelerra to put all the pieces together.  Using the drag and drop editor I put the
individual scenes and mixed my desired audio clips.  Then rendered the project to a DV file.
I did run into it crashing a few times but it did recover perfectly.  It really was minimal
though and basically just worked.  I'm sure I used a very small percentage of the capability
of the software as the only effect I used was a "Title" effect to put text upon the finished
video.

The finished product was rendered by kino.  I took the DV output from cinelerra and created a
Flash video.  Maybe this could have been done by cinelerra but since I knew kino did a nice
job with this I used it instead.

Here is a link to the project if anyone is interested.  It's a spoof of the Ghost Hunters TV
show.

http://www.spectralreview.com/2008/02/25/kitty-ghost-hunt...

or on YouTube:

http://youtube.com/watch?v=ywkLdnmAnSc

Thanks again for your work on this article.  I was happy I was able to do this project under
Linux but look forward to the day when I could use one polished app to get it done.  I did put
all the Free Software I used in the credits of the movie.  Should have mentioned LWN but
forgot.