From a channel in many boxes to many channels in a box

The last decade or so has seen a mushrooming of television channels. Stations have added 24-hours news, sports channels, and mobile channels to their multiplexes. The large content owners have spawned movie channels and themed channels. But this explosion in the number of channels has fragmented audiences. Although revenues remain strong for prime networks, other channels look to minimize operational costs. The demand for channels has driven down costs for master control equipment, with vendors leveraging commodity IT platforms. The lowering of costs has conversely enabled more channels to launch, feeding the seemly endless demand for channels to serve cable, satellite and IPTV viewers.

The old hardware-centric model of automation stems from the early days where the need for realtime operation, with absolute frame accuracy, naturally led to designs based around traditional video processing: the master control switcher and separate video servers and cart machines. The equipment was usually controlled via RS-422 serial communications, supplemented with GPI triggers. An automation chassis needed special cards with the requisite number of RS-422 and GPI ports to drives switchers, video servers and CGs. This interfaces are not a conventional IT component, and called for bespoke designs just for the broadcast sector. The chassis also needed a house timecode input for synchronization, again not a commodity IT component.

Most equipment can now be controlled via IP over Ethernet, removing the need for the interface cards. Even sync can use Network Time Protocol (NTP) over IP. The end of the tape machines removes the need to control the cueing of tapes, catering for the ballistics of the transport. However, if the function of server and switcher could be integrated into the automation computer chassis, the need for all the control interfaces goes away. The remaining issue is base-band video and audio. That needs a video card with SDI in and out.

Channel in a Box

Much of the recent marketing and development efforts in the sphere of broadcast automation have been centered around the “channel-in-a-box”. These products collapse the functions of video server, switcher and graphics, along with the playout automation, into a software application running on commodity IT hardware with the I/O handled by a video interface card.

The issue is perhaps not the one box solution, but the fact that software running on a computer server replaces dedicated broadcast hardware like master control switchers and video servers.

Conflating functionality can save processes, as the external communications and synchronization between devices are replaced with more efficient interprocess communications within the automation application. This means more bang for the bucks out of the CPU.

The first step in the integrated solution was to combine the automation with a video server and keyer using a commodity server platform. The need for audio and video I/O led naturally to the channel in a box, with the interface card occupying a PCI slot. More channels means more I/O, and is it simplest to run each channel on a single server.

Caution Prevails

Broadcasters are naturally reluctant to change their automation systems. The revenue stream of the station, the commercial spots, emanate from the automation system. Any stalled video, clipped frames or other quality issues mean a makegood—a direct loss of revenue. So caution prevails.

As the processing power of computer servers has increased radically over the last decade, it has become very possible to run all the functions of a master control channel on a single IT server chassis. As well as using the CPU, any vendors are also using hardware acceleration from the graphics processor (GPU) and using I/O cards with onboard video processing engines, with Matrox being a popular choice.

NLEs have used commodity computer platforms since the 1980s, but they use operations like pre-rendering of dissolves and effects to save the load on the processor. They also use hardware acceleration in all but the latest implementations.

Playout is different. Everything must be performed on the fly. The defining factor for automation is whether the platform can perform all necessary realtime operations within one television frame. That way frame-accuracy can be achieved. However, some operations present a varying load to the processor, graphics being one. A poorly designed automation channel may run out of resources during complex graphics sequences. During commercial breaks, the only operation is to run each commercial, so the revenue stream is protected, but the discerning eye may see stalling in graphics interstitials. Over time Moore’s Law will eliminate this issue.

No baseband?

Many master control operations are playing out compressed files from disk, or receiving MPEG files streamed from remote locations in SMPTE 2022 format, RTP/UDP over IP. Such streams can be delivered to the automation server over Ethernet, with no need for conventional SDI interfaces. Where SDI interconnections are needed, a gateway can link the baseband and IP domains.

To feed IPTV or mobile, there is no real need for SDI and the goal of running a channel on a commodity IT platform becomes a reality

Disaster Recovery

It is the wish of any channel with good revenue to provide business continuity though any disaster that may prevent the operation of the master control. Unusual weather events or earthquakes are potential problems, or other disasters like fire and floods. To provide a complete mirror of playout operations can rarely be justified, but some compromise operations which keep the brand running is perfectly possible. Cost is key for any disaster recovery facility.

The move to file-based operations has been the catalyst for more broadcasters to consider the cost of setting up DR. The cost of copying and transporting tape made DR operations very expensive, but now files can be simply replicated to a site possibly thousands of miles away, the economics have changed radically. A tapeless operation, generating an MPEG transport stream become a wholly software operation, with no need for baseband video.

Such a system could even be virtualized, running on a blade chassis, maybe even in a private cloud. Using multiple multicore CPUs deliver huge processing power. It becomes possible to run many channels on a single server, currently 16 channels can be run on a single machine, and number will increase. So we have truly moved from a channel running on many boxes, to many channels in a single box (see figure 1).