Master control has an auspicious sound to it. When you hear the words master control, you think of a technology that keeps everything running perfect — well, partially.
The function of master control has significantly changed over the years. For starters, it used to be responsible for just getting one NTSC channel on the air. My first job outside of a studio was in a public TV station running MCR, which the station called air operations. I was the duty director. I read the log, found the media, loaded film and tape when there wasn't another operator around, rolled the media, and did the air switching. The booth announcer (when was the last time you saw one of those in a local TV station?) waited for a hand signal while keeping an eye on the monitor. We had NAB carts for some voice-over content when there wasn't an announcer. There was no local editing, so promos were all live.
Contrast that early 1970s norm with the early part of this decade. Ten years ago, operations were usually live or syndicated content on tape, or server. Promos were always prerecorded. The booth announcer had retired, or at least only cut tracks for a short time per day for each station he supported. And MCR was seldom more than a two-man operation. If the station was automated, it may have been unmanned at times (overnight or weekend graveyard shifts). Manually rolling content hadn't disappeared, but increasingly automation at least stacked the events and rolled them more often than not. Reconciliation wasn't comparing the paper air log to the original from traffic, but rather an electronic process. It's been a pretty amazing transformation. Master control has changed even more in the past six to eight years. The dynamics behind the change are not at all obtuse; they are obvious.
Driven by costs that grow when revenue is flat, broadcasters have increased their dependence on automation and other labor-saving measures. Implementation of a file-based workflow, servers for recording and playout of syndicated content as well as interstitials are now almost a requirement.
Just as costs have impacted the playout side of the operation, they have also affected the syndication and duplication business. Twenty years ago, tape delivery of content was replaced by satellite delivery. This is now being replaced by delivery services that take content from syndicators, add the appropriate metadata and deliver it to servers in the broadcaster's facility without intervention by the operations staff.
Early implementations were developed initially for news delivery from network news departments to affiliates. They could not transfer files directly to online servers for air. Over time, standards for file interchange have become available, and IT file transfer is now a reality.
The rub today is that HD delivery of long-form content is still a work in progress. Bandwidth for delivery is somewhat of a barrier, but the bigger issue is that the delivery networks were designed for much smaller file sizes than HD. One solution would be to use H.264 to gain more efficiency. But, of course, video servers have yet to embrace H.264 for air operations. That would mean a transcode of all content, which is an inelegant process.
Another major change in the last decade is the deployment of centralized operations in many broadcast groups. NBC Universal, McGraw-Hill, the New York Times and other groups have settled into reliable, cost-effective networks for their stations. Many groups, like Sinclair, have a few local hubs running where geography works to their advantage, lowering the interconnection cost to acceptable levels. The balance is labor savings against the operating cost of interconnection bandwidth.
Several years ago, I helped conduct a study of centralized operations in public broadcasting, with interesting results. In some cases, clusters made great financial sense. In others, particularly where labor costs were low, it was difficult to get the numbers to work.
Because of the deterioration of the economy, many groups are looking at options again, which could make this an interesting year. Without fundamental change in broadcast cost models, the landscape of broadcasting could look quite different in a few years. Centralizing master control is not the whole answer, but it is worth a careful look when cash flow is down as badly as is predicted this year.
Compressed bit streams
MPEG-2 has already impacted our industry in a material way that changes the very fabric of master control. When the standard was first demonstrated, it seemed impossible that we would find ways to manipulate compressed bit streams. Today, we can not only switch (splice) signals, but we can also do overlays, bugs, crawls, dissolves and complex graphics without decoding to process.
FOX has been using a compressed stream splicer for several years to deliver its HD content. One might argue that a splicer is not a master control system, but to be perfectly honest, it isn't far from one. This year, expect to see a new generation of products that will make an all-MPEG MCR attractive to broadcasters.
Finally, the most insidious change is the proliferation of multistream needs. DTV has brought new opportunities for revenue, but also the requirement to produce more than one stream, with minimal if any additional factory labor and as small an increment in hardware as possible. This has materially changed the practical technical model for master control. More streams means more server I/O, multiple stream automation, repurposing engines for nontraditional release channels, and a more complex monitoring environment.
The master control engineer is now as much a quality control supervisor as an operator. Monitoring automation, transmitter remote controls, archive systems, satellite record controllers, edge cache servers from delivery services, and other tasks that largely happen on computer screens rather than video screens has become the primary job of the master control engineer. The immediate impact is a new set of skills and training requirements beyond anything we dreamed of 30 years ago.
John Luff is a broadcast technology consultant.
Send questions and comments to: email@example.com