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.”
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide