The broadcast industry is increasingly dominated by IT and commodity technology. Over the past 10 to 15 years, video servers and IP video streams have gradually replaced conventional tape machines. For broadcasters, the move to digital is almost complete. However, our automation and playback facilities are still largely based on proprietary and hardware-centric solutions.
Even so, other areas within television stations use multiple digital systems and various types of IT storage. In addition, stations often rely on a variety of digital tools such as NLEs, graphics and storage platforms. In essence, most of these non-MCR applications have been developed on PC-based platforms. These solutions, including editing graphics and creative tasks, are commonly running on software with PC or Mac hardware support.
These changes show the gradual shift from dedicated hardware systems to software-based solutions. One area where that transition never really took place is in the transmission output chain.
Broadcasters still rely on a large amount of dedicated hardware such as video servers, mixers, keyers, subtitle inserters, voiceover boxes, video effects devices and controllers. Making all of them talk to each other is the job of the facility automation system. These systems must send messages to interface boxes, which then talk to all individual tape machines, servers, CGs, routers and switchers to coordinate all their separate operations to create a smooth and professional playout channel. The question then becomes: Could this divergent range of hardware be replaced by an integrated software-centric solution?
A software solution
To address this question, OmniBus launched a project intended to see how much of the typical hardware-based automation and on-air playback system could be replaced with a software-based solution.
From the technical perspective, the challenge of automating a transmission chain using only commodity software and hardware requires new thinking. Clearly one of the primary benefits of such a solution is the lower cost of implementation. When complemented by software that has years of on-the-job evolution, the result should be a flexible and affordable solution that offers fast and reliable performance in the broadcast environment. However, it's still software, and careful choices must be made.
Technical challenges
Step one is to select an operating system — in this case, Microsoft Windows XP with 2003 server. Most engineers realize that Windows is not a real-time operating system. In fact, the chances are that your own IT department has difficulty keeping your e-mail system running for more than a few hours at a time. Even so, the reality is that Windows-based machines run some of the largest and most mission-critical systems in the world. And, the huge advantages of using an open and well-supported development environment far outweigh any perceived reliability issues.
Finally, because the goal of this project was to see if standard software would be sufficient to achieve our goals, selecting a specialist real-time OS would defeat the objective.
Frame accuracy
The playback system is designed around Windows' DirectShow framework. This framework provides needed pieces of the solution, including software decoding. It also allows the selective replacement of some functions where the demands of the broadcaster are beyond what the platform can provide.
The first priority for any broadcast automation system is to ensure absolute perfect playback. This means a software-based solution must achieve absolutely reliable full-resolution video playback. Unfortunately, while Windows Media Player will satisfactorily play back a broadcast resolution video file, it might play a two-hour movie in two hours and 30 seconds or two hours and three seconds. It all depends on what other tasks the PC is doing at the time. To achieve frame- accurate playback, a broadcast system needs sufficient input buffers upstream of the software decoders and an accurate timecode-locked master clock.
Broadcast automation systems rely on hardware-based mixing and DVEs. For effects and video mixing, software-only solutions are tougher to implement. While Windows supplies mechanisms for blending video pictures together, it does not provide anything like broadcast quality and performance. However, using AMD processors, it's possible to blend two full-screen broadcast images together in less than 30 milliseconds.
However, this is too long for professional applications. By using current DSP functionality, it's possible to reduce the average time to blend two full-resolution video frames together to less than two milliseconds, well within broadcast tolerances.
Managing processor threading
Windows is a multi-tasking environment. This means that on-time performance is not guaranteed. To achieve real — time performance, one has to build a control mechanism for threads. Once this is in place, a system can reliably provide smooth transitions between consecutive video streams and an output frame/field that is always on time.
A similar technique can be used to provide independent control of downstream logos with full linear key support. One advantage of a software solution is that the automation system is not limited in the number of logos that can be placed on screen at any one time. In fact, the screen can be filled with logos, all without a glitch.
The completed software architecture is illustrated in Figure 1 on page 44.
Vision effects for dual simultaneous streams are handled by being read from the storage module, moved across the LAN in chunks and stored in software buffers. Then the data is passed to the DEMUX, which splits the stream into its component parts for graphics processing.
Media file decoding
The software decoders use the plug-in architecture of DirectShow. This provides the ability to select from a wide variety of third-party decoders for different content types.After the decoder, the image is scaled and sub-sampled into the correct size and shape for the defined output resolution. This can range from Web-quality SIF and QSIF right up to HD 1920×1080. Obviously, HD requires much more processing horse-power, so dual-core AMD processors are needed.
Media can be ingested by the automation system by recording from a conventional video source using real-time encoding into a Windows Media file on the server. Or, video can be delivered directly into a directory on the content server. In this case, the media is automatically registered with the database and then copied into a designated folder. Content can also be sourced directly from an existing broadcast server. Or, content can be placed onto a server from outside NLEs or workstations.
Playout
One advantage of a software-based system is the ability to provide a user-friendly GUI. A simple drag-and-drop user interface can control multiple output channels. Because a software solution is format-independent and bit-rate agnostic, operators can intermix DV25; MPEG-1, -2 and -4; AVI; and Windows Media 9 files. Media of any resolution can be incorporated, and the software automatically scales it to the correct output format. This allows SD and HD content to be mixed on the same playlist.
Other standard automation features can be easily implemented with software. This includes character generators, subtitling, VBI insertion and interfaces with external systems. Figure 2 show a software-based ingest and playout system.
A software solution
So, can broadcast automation be handled via software only? The answer is yes. Fewer moving parts than infrastructures built on multiple hardware vendors means there are fewer potential points of failure. Also, a software-based solution relies on inexpensive hardware that is produced in volume. Such components are manufactured through a proven process and can be readily replaced or upgraded as necessary.
A software solution also is supportive to a mixed output channel approach to playout. This means broadcasters can begin by using IP-based systems as a backup transmission platform or for running new low-value channels and new streams with a much lower startup cost. In effect, stations could mix and match, running conventional and IP-based solutions side-by-side within the same facility.
The bottom line for both traditional and new broadcasters is that a software playback automation solution is worth consideration. In addition to being less expensive than more complex, device-dependent infrastructures, the IP-based model can be easier to install and maintain.
Ian Fletcher is chief technology officer for OmniBus Systems.
