Movie Making on a Linux Box? No Way!

Years ago there were these HPUX, IRIX and AIX boxes in the back of college computer labs that did nothing but basic computer infrastructure tasks: file serving, database management, number crunching and maybe a bit of eye candy here and there. If you wanted all of the fun stuff, you had to reboot a Windows PC a few times and wait for the horrendously slow 75Mhz Pentium chip.

But the UNIX boxes were so much faster and efficient than PCs of the time, and a UNIX box editing sound and video seemed like it would transcend all concepts of speed. However, no such software existed. Nothing existed to unify all those efficient utilities and system drivers into a single purpose. Getting a C program that could shuffle gigabytes of sampled audio and video data around in a system, and compile from scratch on thousands of variants of UNIX seemed like the perfect plan.

Windows and Mac advertisements constantly push ways to convert your Windows and Mac workstations into a movie studio. Meanwhile Linux was still pretty much adopted as computer infrastructure glue. If you scour the Internet, however, you might see a few people putting movie studios into a Linux box.

Broadcast 2000 is the Linux movie-making spinoff of mainstream computing in 2000. What Broadcast 2000 does is turn your Linux box into an iMac, a system able to capture, edit and render high-quality multimedia content. The software catapult you into a fury of content sensations normally reserved for those who earn their living by rebooting WinNT.

The Broadcast 2000 software allows you to cut and paste hours of full-motion, full-resolution movies and DVD-quality sound in an instant. The software spits out 2 gigabyte movie files like poptarts. It exercises the full potential of Linux, and most importantly it crosses the barrier between pure computing infrastructure to productivity applications, which is a challenge akin to landing a human on Mars.

Trailers from before 1998 can be transcoded to uncompressed Quiktime by xanim, an exporting edition. Since only the video track has a play icon, only the video plays back. Since each track has a record icon, each track is affected by selections.

It is hard to get programmers who choose Linux based on its tight implementation of basic computer science to focus on movie studio programs. It is even harder to get corporations to support productivity applications in Linux. Impossible tasks like this usually require brute force: sponsors, venture capital and old fashioned full-time programming.

But given enough brute force, Linux boxes can be found recording TV shows, editing commercials, editing home movies, arranging audio CDs, transcoding movies between formats, recording time lapse movies, archiving VHS tapes and playing directories full of MP3s. So which activity is going to enthrall you the most? Probably the installation, right?

The preferred method of installing Broadcast 2000 is to download the RPM and invoke

rpm -U --nodeps --force <filename>

All you have to worry about is matching the following libraries to the point release:

XFree86 4.0.1<\n>
Linux Kernel version 2.2.17.

Most problems occur with the RPM command usage. The three options are mandatory since RPM does not cope with the point release fragmentation in the operating system.E-mails to the Broadcast 2000 support staff usually deal with having an RPM system on the Linux box or not having root access. There is an archaic utility called rpm2cpio that substitutes for RPM on these systems. You invoke it in the following sequence:

rpm2cpio <rpm file> | cpio -i --make-directories

This creates a mini usr tree in your current directory, containing a complete installation. Invoke ls -lR usr to view the complete directory tree.

Be sure to relocate the installation to the real /usr directory if you have root. Trying to install Broadcast 2000 without root can be very difficult if you are not familiar with runtime libraries. It is worth it to buy your own Linux box so that you can get these problems out of the way.

The script file usr/local/bcast/bcast2000.sh contains the proper runtime library path. If you relocated /usr/local/bcast you must change BCASTDIR to the new location of /usr/local/bcast/.

Despite the existence of binaries, one-third of the downloads that include Broadcast 2000 from heroinewarrior.com are source code. There are a number of reasons for this: you can learn about optimization strategies by passing different compiler flags; you can also get greater independence by re-enacting as much of the software development process as possible.

Building from scratch is very difficult and time consuming. Most of the libraries required in the executable are statically built by the master Makefile to greatly simplify compiling. In recent years however, many new point releases have emerged, compounding the home-compilation outlook. You need the include files for the following point releases:

XFree86 4.0.1.
Linux Kernel version 2.2.17.

This can be done by issuing

./configure<\n>
make
make install

in the top directory. There are undoubtedly going to be problems with newer Linux derivatives that we have not seen yet—and you may need to do some hand coding. If it does not build a point release, mismatch is the likely cause.Issue the command /usr/local/bcast/bcast2000.sh to start Broadcast 2000.

Once installed, Broadcast 2000 can perform many operations with a myriad of configurations for each operation. The operations include many alternatives for video capture and audio capture. The system is designed to scale from basic audio to high bandwidth video, but this subjects users to incredibly detailed customization.

Configuration options are described in the /usr/local/bcast/docs directory. The biggest help is going to be trial and error until configuration profiles are developed.

Let us look at the three stages to a Broadcast 2000 session: acquiring footage, editing footage and saving a show.

Commenly, e-mails sent to support complain of being unable to load movie files. Most users want to load compressed Internet trailers, but in 1998 the Linux world came to a hard reality. None of the new compression formats were going to run on Linux. Since then we passed three generations of video on the Windows platform, but not a single one was licensed for Linux use.

The only videos that you are likely to play back are MPEG-1, uncompressed Quicktime and DV. Quicktime is not a single compression format. It is really a wrapper for many different video formats. Some of these formats are used in professional studios and some of them are fully supported in Linux. There is also support for loading high-resolution photographs, panning and zooming.

Then of course you can impart footage through video capture interfaces. In a practical sense, there is no footage on the Internet that you want to use in a show, and compression is never used as an intermediate format. When you leave the pure playback domain, all the footage is uncompressed and captured from some esoteric device.

Broadcast 2000 supports Video4Linux, Video4Linux 2, Firewire, LML33 and screencapture interfaces, which are customizable from half duplex audio recording to full duplex video recording. These hardware applications vary in the degree of difficulty of installation. Video capture is usually implemented in the kernel by patches, separate source code distributions, compilation and hand coding.

After aquiring footage, the biggest problem that people face is editing the interface. Unlike most of the current trends in GUI design, Broadcast 2000 uses a cut and paste strategy. This mechanism allowed precise editing for many years but seems to have shifted out of vogue.

Selecting video is best accomplished by scrubbing: fast-forwarding, rewinding and inserting labels. Then you select the region between the labels by double-clicking on the time bar. Selecting audio can be done just by looking at the waveform and highlighting. The key to success with Broadcast 2000 is the use of labels. Old-timers may remember something called “Soundedit 16”, which used the same label paradigm. Here we applied it to video.

Another e-mail that we often see in support is usually “can’t isolate tracks for editing”. Once again an audio paradigm is applied to video. On old-fashioned 24-track audio decks you had 24 “input/repro” switches. This allowed selected tracks to play back while allowing different tracks to be recorded on. In Broadcast 2000 the ability to isolate tracks for editing and playback is provided by play and record toggles.

On each track there is a play and record toggle that allows just the single track to be affected by cursor selections. Editing is thus purely freestyle with audio tracks being interchangeable with video tracks.

The best part of all is that, when editing, the changes never affect the source files. This makes it possible to relocate hours of footage in an instant, and undo commands are limited to a high 500.

One of the techniques of persistent storage rarely discussed in Linux circles is the notion of saving a list of pointers to resources already on disk. Broadcast 2000 has two mechanisms of persistent storage: pointer storage and rendering. The “save as” function saves a text file that contain filenames and positions. Professionals call the text file an “edit decision list”. Many students flunked out of college trying to get edit decision lists to play on their roommate’s computer.

The EDL stores just enough information to reconstruct a show from resources on disk but not enough to transfer across computers. To transfer a show across computers you need to render. Rendering generates a binary file that plays back on platforms.

With a rendered movie, the final stage is compression for the Internet. It turns out that 90% of the production in Internet trailers and clips starts with uncompressed RGB rendered to an uncompressed RGB master and compressed using whatever proprietary compressor is in vogue. In Linux, the final stage would be RealVideo, Mpeg2Movie or LAME. Though not as popular as the proprietary compressor, these Linux compressors actually produce comparable quality.

So you just graduated from MIT and are extremely brilliant. You have vastly greater amounts of disposable income than your peers, and you want to do the impossible. You want to build a Linux box that can produce TV shows.

The ideal target system should be capable of uncompressed, full resolution video playback. A system with lower performance produces a lower quality show even when scaled down to the Internet.

This naturally results in a 45MB/sec hard drive requirement and a 50MB/sec graphics card requirement. Such things are achieved by stringing up several 7,200RPM hard drives on a RAID controller card. At the office we have 75MB/sec through two 10,000RPM drives on a SCSI controller. The RAID controller from Promise achieves 70MB/sec using IDE drives.

Depending on the program length you will need 80GB to 200GB of space. A 200GB IDE RAID gives 107 minutes of play time for under $700. If you are like my buddy at Micron, however, you will build a stand-alone video server with gigabit Ethernet. The cost of persistent storage is dropping quickly.

Broadcast 2000 uses software to produce effects. Color correcting and compositing 100,000 frames-per-hour of movie requires brute force. Linux software tends to get rated on the minimum CPU and screen size it runs on. In the video world, however, it pays to indulge. Dual CPUs running at greater than 700MHz are recommended. Broadcast 2000 enlists the second CPU so aggressively that you will not be able processor machine after you see dual CPUs in action.

Despite these hardware requirements, the RAM recommendation is only 256MB of 133MHz RAM. RAM is only beneficial when you record video. When you record video, Broadcast 2000 buffers unlimited numbers of frames in memory that defeat hard drive latency. For large RAM systems, however, the operating system tries to cache every disk operation. On our 768MB test system, uncompressed video capture occasionally freezes up for several seconds while the operating system flushes 700 megs of disk writes. Of course, avoid using a swap space too. There are many options for video capture.

Capture |Hardware |Recommended driver<\n> option | |——————————————————————————————————–Uncompressed |haupauge |Video4Linux 2analog |WinTV Analog |—————————————————-Firewire |Generic |ieee1394.sourceforge.net—————————————————-Compressed |LML 33 |linuxmedialabs.comanalog | |

Video playback to a VCR can be achieved with the LML33 hardware.

Each of the drivers has one glitch. You will find that the firewire driver is unable to detect a camcorder without reloading the module set a few times. The Video4Linux 1 driver drops frames. The Video4Linux 2 driver loses sync. And the LML33 swaps field order. But overall a Linux system can be made to generate professional quality video inexpensively with any of the solutions listed above.

Most of the analog video capture drivers are the result of reverse engineering, persistence and delayed graduations. It was once thought that companies would eventually finance their own Linux drivers or at least document the chip sets. That never happened. This combined with the high cost of video hardware is going to keep Broadcast 2000 from working with most video I/O cards.

The good news is that the new digital TV standards eliminate variations in quality between boards and the need for many drivers with different coding conventions. Each member in the current canon of drivers uses its own coding convention that takes about three months to test and conform to. The current drivers use everything from DMA, FIFO, read/write primitives, stdio primitives, select calls, function overriding and callbacks. This is because the quality of analog video changes for every card. Under the digital system, programmers can have access to the highest quality video by hopefully using only a single coding convention.

The next developments for Broadcast 2000 are updating the interface to future GUI trends, updating the function prototypes as new kernels and C library conventions come out, financing previous development, and hopefully providing new functionality.

Installation is not going to get easier. The installation difficulty arises from many different point releases of libraries being in circulation at any given time. Although aggressive configuration scripts and #ifdefs can temporarily catch up to fragmentation, the real solution is to consolidate the many libraries and sublibraries, consolidate the many kernel options like “Use memory if detected” and preconfigure systems. In October 2000 several companies sold preconfigured Linux boxes for movie making. One was Linux Media Arts. Others may jump into the art of media creation on the Linux platform.

The trend is now to isolate the Linux interface from user interaction by embedding it in microcontrollers, appliances and computer infrastructure. Part of the justification for Broadcast 2000 is to invent roles for Linux that no one never dreamed of before. It is all about web servers playing movies and routers playing reverb. As a colleague once said on the topic of 3-D webcams for Linux boxes, “That sounds like something only Microsoft would do.”