It is an interesting era for automation and equally challenging for master control. In the broadcast industry, dynamics are at play that converge on both of these topics and force consideration of how they affect one another. Let me explain.
The DTV transition
The DTV transition comes with some implied changes in operation. The number of items that must be controlled is inexorably going up. DTV encoders and multiplexers will require control if the makeup of a broadcaster's multiplex changes during the day, as it does in many stations. Since automation lists are almost universally generated by traffic systems, the issue propagates back into traffic, which must include enough information to provide timed sequences of events needed to set up the emission encoder. The most obvious is the number of playlists sent from traffic to automation, but moreover, there has to be coordination of the setup and teardown of virtual channels in the multiplex and how they are configured.
For example, at a public broadcasting station, the HD programming may run principally during prime-time hours. The rest of the day that channel should not be left running and empty, absorbing bandwidth and limiting quality in the other virtual channels. So at the time of transition, the appropriate commands must be sent to automation, which must then issue the technical commands to effect the change. But what if the HD programming is a cooking show with little movement in the screen when compared with sports? It would make sense to specify the bit rate that will optimize the quality of the full multiplex, assuming the station is not using statmux in the emission chain.
Also, if one of the channels is a local weather channel, it would require a low bit rate for acceptable quality because so much of the screen is essentially static. As with the previous example, that control may need to start in traffic.
Updated program guides
There is another issue affecting automation and master control that came up in the FCC's Dec. 31 third periodic review report and order FCC-07-228. The FCC heard complaints from consumers about program guides not being up-to-date, specifically if a live event extends, as happens often with major sports.
The FCC has determined that: “The updated ATSC PSIP standard … requires broadcasters to populate the EITs with accurate information about each event and to update the EIT if more accurate information becomes available. We expect broadcasters to fully implement PSIP to the extent that ATSC A/65C requires … We remind broadcasters of the need to be consistent at all times and locations. … [B]roadcasters must accurately fill the contents of the fields and the descriptors of each event … and shall update each field if more accurate information becomes available.”
The effect of this ruling appears to be a requirement that real-time changes in program content be reflected in PSIP as they happen. Of course, information about live event changes is not available in traffic systems, because the connection between the two databases is one-way and not live. Rather it's done on a scheduled basis in almost all cases.
To make matters worse, few stations populate PSIP from the traffic system, which does not contain detailed program descriptions. Instead they populate PSIP from services like Tribune Media. It is not clear how this can be changed, especially in the timeframe indicated, which appears to mandate the change as quickly as mid-2008.
New ways to generate PSIP changes using information derived from real-time data available only in automation systems will likely be required. Implementation will be at best difficult and at least require changes in station workflow.
To make matters more complicated, downstream program guide information is gathered into composite program guides for satellite and DBS service providers. Although the FCC has not addressed this extended part of the issue, it is clear that only over-the-air reception will be helped by the FCC's December mandate without further rules that are sure to be resisted by other service providers.
Adding BXF to the mix
This underscores the tight integration that will be required in master control between traffic, automation, PSIP and complex devices in the program chain. It also makes clear that it is no longer possible to think of a modern DTV origination system without automation. For decades, there has been a vigorous and valid conversation about whether MCR needs to be automated or not and whether alleged cost savings are real in markets where labor costs are low. However, as the complexity of the systems grows and the number of live actions that must be taken increases, it is becoming impractical to operate manually.
At least there are some positive developments in the industry. The SMPTE work in the standards committee (S22.10) on communication between devices and systems in the station control and automation loop, the Broadcast eXchange Format (BXF), can provide a key method of communicating information in real time. BXF is XML-based and supports transport of single instruction messages between compliant applications. For example, if a spot is sold late in the day, messages can be passed to automation at any time to add it to the active playlist and add it to the dub list.
Similarly, the reconciliation process no longer needs to be an offline, after-the-fact process, but rather can be done as each event is completed. The XML code is passed back to traffic after every event. This is the key to making real-time changes in air content transparent to traffic and ultimately to PSIP. Messages to other devices could be passed in the same way, allowing for the setup and execution of complex commands like those discussed earlier. BXF could become a critical part of implementing the increasingly complex structures that stations require.
John Luff is a broadcast technology consultant.
Send questions and comments to: john.luff@penton.com
