It LiVES! Video Editing For FOSS Movie Makers
Studio Dave is set up for personal audio production, but video capabilities are on the horizon. Digital video cameras are inexpensive and typically non-problematic with Linux, there are compelling professional reasons to get into video (Web-based tutorials are high on the list), and besides, it's just fun to play with video on the computer. Now the fun level has jumped up a few notches with version 1.0.0pre1 of LiVES, a video editing system for Linux.
On its Web home page the LiVES project states its goals clearly and succinctly:
LiVES mixes realtime video performance and non-linear editing in one professional quality application. It will let you start editing and making video right away, without having to worry about formats, frame sizes, or framerates. It is a very flexible tool which is used by both professional VJ's and video editors - mix and switch clips from the keyboard, use dozens of realtime effects, trim and edit your clips in the clip editor, and bring them together using the multitrack timeline. You can even record your performance in real time, and then edit it further or render it straight away. For the more technically minded, the application is frame and sample accurate, and it can be controlled remotely or scripted for use as a video server. And it supports all of the latest free standards.
For an old experimentalist like myself LiVES is a cornucopia of video editing delights. The program supports MIDI, OSC, and best of all, the JACK audio server and transport control system, which means that I have a variety of interesting control scenarios. LiVES + Ardour, LiVES + Csound, LiVES + Rosegarden, LiVES + AlgoScore + AVSynthesis, the list of possible connections goes on.
The features list on the LiVES Web site states that the program scales well to high-end and low-end hardware, but it doesn't indicate a lower boundary. Frankly I wouldn't want to try serious amounts of editing without a 2 GHz CPU or better. A large fast hard-disk is needed, as is a fast video subsystem. If you have a working FireWire connection and the right driver a DV/HDV-capable camcorder is a nice option. LiVES will import video from such cameras, but alas, the Web site gives no particular recommendations for compatible hardware.
The Dependency Tango
As of June 15 the source code for LiVES 1.0.0pre1 has been available from the project's Web site. Prebuilt binaries are also available for Debian, Ubuntu, Fedora, Arch, Gentoo, and other Linux distributions. I prefer to compile programs from source, so I downloaded the tarball, installed the sources in my $HOME/src directory, and I was ready to roll my own. Btw, I intended to build LiVES for two systems, a 32-bit version for my JAD 1.0 box and a 64-bit version for my 64 Studio 2.1 machine.
I've built previous versions of LiVES on both machines, so I was prepared for its needed dependencies. Those dependencies are considerable, so before you build or run the program you should check with the LiVES Web site for complete information regarding the required and optional support software. If you want the fully capable LiVES you'll need the mplayer/mencoder packages, ImageMagick, Perl, SoX, and many other recommended packages.
Once the dependencies are present and accounted for the build itself is anticlimactic. The standard autotools mantra of ./configure; make; sudo make install does the job. If all goes well the program is ready to begin its work.
Open an X terminal, enter lives at the prompt, and you'll soon be greeted by a display similar to the screenshot in Figure 1. By default LiVES opens to the clip editor, but before you do anything else you should set up the program's Preferences (Figure 2) to match your system capabilities. Fortunately LiVES makes a good attempt at setting default paths and values, but for best results you'll want to tune its configuration as finely as possible. Make sure you set aside plentiful swap space, and make sure you have the JACK sound server installed.
JACK is not absolutely necessary for LiVES, but some of its coolest features depend on it. Alas, JACK is not a typical component of the general-purpose Linux desktop, though it should be available for all mainstream Linux distributions. Serious Linux audio producers will have it installed as a matter of course. Tabulating JACK's virtues is beyond the scope of this article, so I'll refer readers to the JACK Web home for current in-depth information. However, it is worth pointing out that JACK is specially designed to work with a kernel patched and configured for low-latency performance, so if you plan to use it make sure that you also have access to a modified kernel. Fortunately most mainstream distributions now include a realtime kernel in their repositories. Check with your package management software to see if an rt kernel is available for your distribution of choice. Further adjustment to your system may be necessary before you can enjoy the benefits of low-latency realtime operations. See the JACK FAQ sheet for complete instructions.
Okay, you have a low-latency kernel, JACK is present and correctly configured for realtime performance, and LiVES starts up properly. You may note that when the program opens it lists the support components compiled into the binary (see Figure 1). Assuming no faults or showstopping bugs we're ready to work with LiVES.
As I mentioned, LiVES starts up with its clip editor screen. On this page you load and view the video and audio files you want to use in your project. You can also add effects, perform cut/copy/paste operations, and utilize the realtime VJ tools. For the purposes of this introductory article we'll stick to the basics, but I must emphasize that the LiVES GUI is simple to comprehend and navigate. The program is easy to learn, and you'll soon find yourself looking into and testing its advanced features.
First we'll open a few video files, with the intention of setting them together to make one video from many files. The resulting collection is known as a clip set. Your clip set is your pool of video and audio data available for editing in the clip editor or for layout in the multitrack mode. I'll have more to say about that mode in a few moments, but for now we'll load those files and view them with the playback controls in the clip editor screen. Acceptable video files include all types supported by mplayer. I've loaded AVI, MPEG, FLV, WMV, and other file types with no troubles, though it is possible that some files won't load. The world of video codecs is more bewildering than the world of audio formats, and it may be necessary to rebuild mplayer for support of a relatively uncommon file format.
File size is unrestricted, but you will receive a warning if your file is 500 MB or larger. The warning merely advises that a large file may take a long time to load, and the message itself can be toggled off in the Warnings tab of the Tools/Preference dialog.
Once a file is loaded you can edit it whole or in parts. A lengthy list of video effects provides a variety of cool and useful ways to bend, fold, spindle, and mutilate your content. Fade-in/fade-out, swirl and wave effects, pixelization, color cycling, and many other effects are available, any and all of which can be included in batch scripts for complex and repetitive edits. It must be noted that these effects vary in their need for your machine's resources. CPU speed is a limiting factor, and some effects require some awesome power if you want the fastest performance possible. Make no mistake about it, video editing is a heavy hitter, and it wants heavy resources. LiVES is usable on low-powered machines, but for greatest satisfaction you'll want a 2 GHz CPU and fast disk throughput.
When you're happy with the condition of your clips you can switch to the Multitrack mode screen (Figure 3). This page is where you add your clips to a timeline for eventual compilation into a single video file. Just drag and drop your clips from the collection to any point in the timeline, press the Play transport control, then edit the results as necessary. Repeat the process until you're happy. When happiness reigns it's time to render your layout of clips to a new video file. Open the Render menu, select Render All To New Clip, and the process starts immediately.
By the way, the layout seen in the screenshot is a mixed collection of AVI, FLV, M4A, MOV, and MPEG video files. LiVES loaded each one without complaint or warning.
A session's collection of video and audio data is saved as a clip set. In the Multitrack mode the arrangement of data selected from your clip set is saved as a layout. Finally, your multitrack audio/video layout is rendered to a file. Supported file types are defined by the selected encoder. For my first experiment with LiVES the default output was a DIVX-encoded video file in an AVI container.
The VJ Tools
Realtime video processing brings out the VJ in us all. The LiVES VJ tools include a default key map that applies a variety of realtime effects on a running video. For example, Ctrl-1 applies a rotozoom effect, Ctrl-2 activates an edge detection routine, Ctrl-5 calls up a very weird mirror effect, et cetera. Key maps are defined in the VJ/Real Time Effect Mapping dialog (Figure 4), they can be saved, and any map can be declared as the default map. LiVES provides a generous menu of realtime effects assignable to a key map, but alas, I'm still at the fledgling stage on my LiVES learning curve. For now you'll have to believe me, the LiVES VJ tools are wonderful. Or, of course, you can try them yourself.
Incidentally, if you've installed the excellent Frei0r video processing plugins LiVES will add them to the list of available realtime processors for even more VJ fun and excitement. The use of the Frei0r plugins is yet another example of LiVES leveraging the power of existing open-source projects.
User-level documentation comes in plain HTML or OpenOffice ODT format. While thorough, there is no internal linking between topics, thus making navigation more of a chore than is necessary. Further help is available on the LiVES Tutorial Wiki and the standard comm channels, i.e. IRC, mail-lists, and discussion forums. See the LiVES Web page for more information.
I run LiVES on two machines of roughly equal capability so I compared some file load times and some processing times. My test load was an MPEG video roughly 10 minutes long, with audio. On the 32-bit box the load time was 253 seconds, on the 64-bit iron the load time dropped to 153 seconds. Curiously, the machines reported a different frame length for the same file - 17092 on the 64-bit box, 17194 on the 32-bit machine. I don't know why it happens, but it doesn't seem to affect performance otherwise.
Next I loaded a smaller video (600 frames, about 40 seconds long) and applied a simple Brightness Change effect to the whole file. The 32-bit box took about 200 seconds to process the file, the 64-bit machine took about 110 seconds. Other casual tests indicated that the 64-bit machine was the superior platform for LiVES.
I also experienced some crashes, mostly during Undo operations, and I have advised the programmer about the problem (see the Comments section). More tests are needed here to narrow down the cause, but subjectively it seems that the 32-bit platform is the shakier of the two test machines.
But That's Not All
I've only scratched the surface of LiVES. More treasures await the intrepid explorer, but alas, I haven't the space to get into the many other features of LiVES, such as scripting, compositing, live recording, GUI customization, and transport control via JACK. Simply stated, LiVES is terrific. It's not perfect (I'd like to see waveform displays for the audio tracks, for instance), but it's easy to learn and use, it performs well on appropriate hardware, and it's just incredible fun. Great thanks to Gabriel Finch for his perseverance with the LiVES project. I look forward to its further development, and I hope this article will inspire more users to try this wonderful software.
Limited Time Offer
Take Linux Journal for a test drive. Download our September issue for FREE.
Topic of the Week
The cloud has become synonymous with all things data storage. It additionally equates to the many web-centric services accessing that same back-end data storage, but the term also has evolved to mean so much more.