Movie Making on a Linux Box? No Way!

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

Figure 2. Broadcast 2000 playing a 57 minute WAV file

Figure 3. Traditional Compositing. (Many photos were layered for each scene.)

Resources