NLE Video Editors

Robin takes a look at six Linux video nonlinear editing (NLE) sofware packages: Broadcast 2000, Crow, Kino, LVE, MainActor and Trinity.

Kino is a simple cuts-only DV editor. Kino just released version 0.50, a major new release. To install Kino, you first must install many drivers. That, and installing some of the many other DV-related programs available, makes for a rather involved process.

Kino, a popular Linux editor for DV, just released a new version.

The instructions recommend using the latest kernel to get the best IEEE 1394 FireWire DV support. Using make xconfig, we were puzzled at first that the IEEE 1394 options were grayed out and couldn't be selected. In configuring our 2.4.14 kernel, we first had to select the code maturity menu option to enable the 1394 menu.

The following drivers were next: libavc1394-0.3.1.tar.gz, libdc1394-0.8.3.tar.gz, libraw1394_0.9.0.tar.gz, libdv-devel-0.9-1.i386.rpm and libdv-0.9-1.i386.rpm.

For tarballs, let's follow the standard procedure:

tar xvfz libdc1394-0.8.3.tar.gz
cd libdc1394-0.8.3
make install

Those that came as RPMs we installed using Alien. If you build libdv from the tarball you will need to install pkg-config first to run configure successfully.

The libraries include some simple tools. Included with libraw1394 is testlibraw. Let's start with that to see if it detects our FireWire cards. We have two FireWire PCI cards in our Athlon PC, a PYRO card and a no-name FireWire card included with our FireWire scanner. Both are OHCI-compliant, and detect properly. However, we had to chmod the device to gain permissions access for ordinary users.

chmod 666 /dev/raw1394
  successfully got handle
  current generation number: 3
  2 card(s) found
    nodes on bus:  1, card name: ohci1394
    nodes on bus:  1, card name: ohci1394
  using first card found: 1 nodes on bus,
    local ID is 0, IRM is 63

The libavc1394 romtest program enumerates the ROM information of any attached FireWire device. It correctly detects our Sony TRV8 DV camcorder.

Included with libavc1394 is dvcont, a remote control for DV camcorders. When using dvcont the first time, specify dvcont help, so you know what the commands are. If dvcont can't find its drivers, it exits immediately and won't even display help. You may need to modprobe video1394 and raw1394. With no command specified, dvcont does nothing. With your camcorder in play mode, executing dvcont stop causes the camcorder to stop. There are similar commands for the other camcorder functions.

Listing 2. modprobe

Included with libdv are playdv and encodedv, but both died with segmentation faults. These are supposed to play or encode a .dv file.

Here are some of the many available DV programs that may be useful: dvgrab-1.01.tar.gz, gscanbus-0.6.tgz and gstreamer-0.2.1.tar.gz.

We couldn't build coriander or gscanbus. gstreamer built, although it took a long time and then died with a segmentation fault. The tool we really wanted from this set was dvgrab, so we could do a console test of DV capture. Since it didn't prevent us from using Kino, we didn't stop to investigate why we had problems with some of the DV tools.

The dvgrab utility will copy a video playing on your camcorder to your PC. It has no device control, which means if the camcorder isn't in play mode, dvgrab simply waits. If no FireWire DV stream is detected it won't do anything.

dvgrab --frames 30 test
ls -l test*
  -rw-r--r--    1 rower    rower
  2471424 Nov 17 17:27 test001.avi

We grabbed a second of video as a test. It was saved by dvgrab as a DV stream wrapped in the AVI transport. Arne Schirmacher created dvgrab and Kino.

We initially built the 0.46 version of Kino (kino-0.46.tar.gz), but 0.5 was released during our evaluation (kino-0.5.tar.gz). At first we had a problem building Kino because configure couldn't find gnome-config. That seemed odd since we had GNOME installed (on Debian Sid). Doing a search for it in dpkg should report gnome-config in libgnome-dev (as shown below), but we came up empty.

dpkg -S gnome-config
  libgnome-dev: /usr/include/libgnome/gnome-config.h
  libgnome-dev: /usr/bin/gnome-config
  libgnome-dev: /usr/share/man/man1/gnome-config.1.gz

Kino developer Dan Dennedy suggested that we install Ximian GNOME because that is his configuration. So we added a link to our sources.list and installed it:

vi /etc/apt/sources.list
deb stable main
apt-get update
apt-get install task-ximian-gnome
Installing Ximian created massive conflicts with already-installed GNOME components. We had to uninstall many packages that were reported broken by apt-get. It was actually a lot more effort, but the example shown here represents the gist of the process. Surprisingly, it was the GNOME GTK docs that seemed to have our install the most wedged. Eventually we got Ximian installed as well as the Ximian GNOME development libraries. Kino built without a problem.
dpkg -r libgnome-dev
apt-get build-dep libgtk1.2-dev
dpkg -r libgtk1.2-doc
apt-get -f install
apt-get install libxml2
Kino is based on a metaphor of the vi command set. Commands for lines, words and characters become movies, clips and frames. Use d0 to set an in-point and d$ to set an out-point.

Dennedy says, “The new version of Kino is a major rewrite, with new user interface, no multiple-floating windows and a storyboard view more like iMovie. You'll notice greater consistency in interface.” Dennedy says the Kino team has a new developer, Charles Yates, who was the major force on version 0.5.

Dennedy notes that the Kino EDL is in XML SMIL format, and that sound support is based on the OSS interface. Because most sound cards don't support multiple opens, esound is only supported with the SBLive! card. The Contour ShuttlePro USB controller ($125) provides a convenient device to control Kino, bypassing the vi-based interface. Kino supports XVideo for better preview performance, but we had to turn that feature off because the preview window became stuck in place permanently on our desktop. That seems to be due to our having installed the wrong version of the ati.2 driver, and not a problem with XVideo generally.

Kino can handle DV1 or DV2 AVI files, but not raw DV files (.dv). The format you choose affects compatibility with other tools. Dennedy explains, “Windows Media Player (WMP) and Linux Avifile will play DV2 AVI format, provided the Microsoft DLL is installed. That's called qdve.dll. MPlayer also can play those but requires adding a line to its configuration file.” Dennedy notes that WMP also can handle DV1 AVI. He says MainActor can handle DV but has no DV camcorder I/O.

Tools such as dv2jpeg can help you move between formats. Dennedy adds, “mjpegtools can read DV AVI to create a VCD; mjpegtools has support for MPEG-1 VCD and MPEG-2 SVCD. Kino will soon export MPEG-1 and MPEG-4 formats based on FFmpeg, but FFmpeg is currently lacking MPEG-2.” And, mjpegtools can split off the DV audio. The tool transcode will convert DV AVI to OpenDivX.

Dennedy is excited that Kino now supports DV export back to the camcorder. He says Kino is the only DV application to offer that besides the libdv console program. Kino doesn't offer a logging mode, and Dennedy doesn't expect it will soon. He says that feature isn't as interesting to the team as adding effects and that a new dv1394 driver is in development that will provide scrub preview in the TV monitor. He also says Kino MPEG export is coming but has no plans to integrate with Film GIMP.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

The best one

forrestcupp's picture

You left out the best one of all: Cinelerra.
It can do anything you can imagine, if you can get it installed.

Re: GFX: NLE Video Editors

Anonymous's picture

Never in my life have I been as mad at the proprietary actions that Apple has pinned on Microsoft for so many years than now. It seems that Apple, our "innocent" company has decided to buy out any and all of good linux cinema software today. If you don't believe me, look at Apple Shake, and also Silicon Grail's Rayz. This wouldn't be so bad with the exception that I rely on many of those applications and use LINUX as my ONLY platform. I am so unbelievably mad that I could just kill!!!

Now I have to spend countless tens of thousands of dollars re-outfitting my VFX studio with new Apple (eww) computers.

Thank God Apple can't take away the price tag of linux, as well as the stability needed to make great render farms!

Signed -

John C. Beck

Re: GFX: NLE Video Editors

Anonymous's picture

umm... why not spend significantly less funding open source development of a new app? There are lots of support libraries out there already, like gstreamer, etc. Filmgimp/Cinepaint is available, and being developed. Add the features you need to open source. No point complaining about the lack of open source, and then buying proprietary junk.

Re: GFX: NLE Video Editors

Anonymous's picture

Because not all production studios have coders on hand to produce apps that could perform those kinds of functions. In that case, hiring the coders to do the work would end up being far more costly and time consuming than switching to an already existing set of apps.