In a perfect world, everything would happen as planned. No human intervention would be needed, and perfection would be achieved 100 percent of the time. Such is the myth of television playout automation. A cynic might remind those who believe this myth that err is human; to really foul up requires a computer.
From many perspectives, computers have made extensive improvements possible in television operations. Station management seeks the Holy Grail of less labor and fewer make-goods. Chief engineers want the ability to supersede operator-training deficiencies that plague manual station operations. Traffic operators want to have it their way without listening to alternative ideas. Salespeople want the ability to sell a spot at 4:55 p.m. and go home at 4:59 p.m. safe in the knowledge that their sales will be fulfilled accurately. The general manager, if possible, doesn't want to do any make-goods.
In a perfect world, everyone could have his or her way. Indeed, automation can move a station towards those goals, but we must remember that automation simply replicates the decisions others have made in other software. It can streamline the workflow and ensure that dub lists are accurate, ensure the right program plays to air at the right time with the right commercials, and add opportunities for enhanced revenue experiences and extra breaks in live programming.
The opposite, however, can also be true. A poorly implemented automation system will never improve workflow nor enhance the accuracy or look of the on-air operation. For instance, the master control room operators in many stations with stable (read old) equipment have learned how to get around any failure without undue impact on air ops. When a VTR fails, they find a way around it. But, when a VTR fails under automation, there may not be a person standing by to ease the fears of the general sales manager. And, even if someone is present, he may no longer have the skills to figure out the smooth path to a clean transition.
Today, automation works by taking the log and parsing the log information into a database of events that processes at precisely planned times. It issues machine-understandable commands to devices usually connected by RS-422, or Ethernet remote-control connections. Automation also collects the responses from the devices (i.e. confirmation that the event really happened) and feeds that information back to traffic electronically as confirmation that the as-run log is the same as that allegedly planned. Sony protocols control VTRs, and servers and other devices use video device control protocol (VDCP) that permits more complex commands including selection of media and sophisticated cueing.
Each single event might be as simple as a cut on the master control switcher to server, play four spots back-to-back, and then a cutback to programming on the switcher. It might also include secondary events, such as voice-over and pushback to reveal a promo or other graphic, a key of the station logo in the corner on the hour, or other events. One problem that often complicates log management is that the log sometimes does not contain accurate machine commands that automation can translate effectively. For instance, at 2000, you want your DTV channel to go from four SD streams to one HD and one SD stream. Consider the number of individual changes that must occur: drop two streams in the multiplexer, increase the bandwidth for the HD channel, decrease the bandwidth for the remaining SD channel, send new information to PSIP, manage the statmux settings, and perhaps dozens of minor commands necessary to make it all work seamlessly. For most stations today, that information is not part of the log. Add the fact that frame accuracy is now critical, and many traffic systems are brought to their knees before they communicate the first byte to the automation system.
Until recently, all commands were generally passed to a device-control engine that kept a master clock synchronized so that all events would happen in lock step. Now, it is quite possible to let each device connect to a separate control interface by using Ethernet and network time protocol (NTP). The automation system can send commands to a local control buffer with the command and the time the command is to be executed. It then moves off to other business, safe in the knowledge that the device will take care of itself. The device controller communicates with an NTP server to ensure it has the precise time to which all other devices have synchronized. Using this structure, you could build up a distributed automation system where you could send commands hundreds of miles away and know they would execute at a precise time. This is ideal for a centralized operation with local automation events. With this structure, it is much harder for a single failure to totally disrupt the air-playback schedule.
One thing is true about all automation systems. Putting accurate metadata on each event is critical. Segmenting a show to get the timings perfect is a vital step in making a well-run system. Spots must be ingested with precise timings for the same reasons because, rest assured, no one is looking at the video to ensure all transitions happen in black — at least not yet.
Modern playout automation can vary from simple server-playlist automation — which controls only ingest and server playout — to global media asset management and playout control of dozens of devices for many channels with redundant control and fault-protected databases. It is still important to look at workflow and make sure that you are improving the on-air operation and not just making it more complicated than it needs to be.
John Luff is senior vice president of business development for AZCAR.
Send questions and comments to:john_luff@primediabusiness.com
