At this commercial insertion facility for a Cox cable headend in San Diego, operations mainly center on ensuring that commercial media and other interstitial material is available and that playlists are complete and correct. The video switcher seen on the console is used only during live sporting events. In all other instances, program stream switching and other transitioning is handled under automation control.
DTV promises viewers many new services. Most broadcasters believe that these services will help stem the exodus of eyeballs from terrestrial broadcasts to cable, DBS and, yes, even the Internet and video games. But, to reap the rewards that dynamic DTV services offer, broadcasters must overcome a host of challenges.
Moving from a single-program service to multiple-program services requires new ways of conducting operations, which often requires new workflows. Over the last couple decades, television facilities have organized operations and workflows through automation software. Automation, in its simplest sense, is a suite of software applications and databases that collaborate to enact the broadcaster's desired business plan with the hardware at hand. Historically, that has meant control of VTRs, servers, routers, switchers and, maybe, acquisition equipment such as satellite receivers. The automation system, along with the traffic system over it, formed an application layer over the equipment hardware layer, which the business and operations personnel controlled via traffic and automation software.
Now that we can add additional services, we usually find that things get a bit more complicated and operations change. We need to bring new systems under automation control, and additional stand-alone systems need to collaborate with automation.
At WXXI’s master control center, elaborate automation systems consisting of a number of applications all communicate with one another in a tightly coupled system to ensure that problems are caught and fixed ahead of time and not at the last minute. The workflow that WXXI has implemented means that operations staff who release multiple program streams to air work mainly on future events and seldom need to react the current on-air events. All photos courtesy SignaSys.
In the “dynamic DTV services” mentioned above, “dynamic” is the operative word when it comes to offering multiple services or programs. Dynamic services change, not only at day-part boundaries, but also throughout the entire day. These services change as program segments change, or during commercial breaks, or as needed during live and breaking events. Examples include expanded sports segments on minor DTV channels during normal newscasts, or a headline program on another minor channel that continues coverage of the lead story during the entire newscast. Opportunities abound in providing alternate coverage of local events, such as parades, sports or just counter programming against others. An extreme example would be airing cartoons on a minor channel while airing football on the main channel. It would be hard to argue that serving cartoon viewers would cannibalize a football audience, but it just might pull some of them away from the Cartoon Network.
As program services and requirements change, this rear-projection “glass cockpit” monitor wall can recall multiple configurations of source monitoring.
To accomplish this Dynamic Service Allocation (DSA), the automation system must also control your ATSC encoders and multiplexers. Most ATSC encoder/multiplexing systems allow you to program “profiles” that define the mix of services — essentially, the number of programs available and the bandwidth devoted to each. Thus, the automation system now must be able to call these profiles as events in a program log. Groups such as the ATSC and the Multi-channel Broadcast Alliance are working on protocols that will allow automation to call different ATSC encoder/multiplex profiles directly, much like VDCP is used by automation to control video-server operation.
Early adopters of DSA operations are programming automation systems to produce GPI triggers when service re-allocation is required. The GPI trigger drives a terminal server that calls APIs provided by the encoder/multiplexer vendor that invoke the desired service profile.
Figure 1. WXXI transmits a number of program streams based on the workflow shown here, implemented via Novus Automation. At the top of the workflow is traffic, which resides at the business layer of the station. The middle applications implement the fairly complex operational processes WXXI requires to insure that a number of high-quality program streams emanate from its facility. The bottom part of the diagram is the hardware layer. Figure courtesy Novus and WXXI. Click here to see an enlarged diagram.
This leads to the fact that multiple services or programs require multiple playlists that must work in concert. Obviously, each program or service needs a playlist. But now, a playlist also is needed to control the encoder and multiplexer. All of these playlists must also remain in sync. In addition, activities occurring on one will usually affect the others. An example is live sporting events. What happens when the game runs over its scheduled end time? If the game is in HD and this HD service is scheduled to be replaced with multiple SD services, what happens? While these are policy decisions made outside of engineering and operations, these two entities will have to implement them.
Statistical multiplexing, or the dynamic allocation of compression bandwidth between encoders as needed (especially now that HD and SD encoders can share the same bandwidth pool), can alleviate some but not all of the problem of bringing up additional services when the previous ones aren't concluded yet. Thus, changes that need to be made in one log often result in changes in all the logs. But wait; other potential changes also will be needed. PSIP tables, especially the EIT and ETT text tables that the set-top box uses to build PSI schedules should be updated.
The ATSC has recommended that PSIP change from a static set of tables to a dynamic stream that reflects current programming operation and conditions. It is likely that the FCC will at some point require dynamic PSIP. The ATSC multiplexer treats dynamic PSIP (which is metadata — data about the audio, video essence and other programming data) as another program. And, from an operational standpoint, you will have to treat it as such. This means that, in the example of our sporting event running long, the ETT table in the PSIP stream should inform the viewer about what is happening to the program schedule.
It appears that the natural place to enter last-minute changes is through automation. That includes PSIP changes. This “one-stop,” last-minute-change operation would allow the master-control operator to enter change information once, and from one application, instead of making separate changes to automation playlists and PSIP tables. Thus, in the future, the automation system also will have to communicate with the system that is building your PSIP stream.
Figure 2. Multiple program streams working in conjunction to form a single transport stream must work cooperatively with one another through broadcast subsystems that did not need to collaborate previously. Figure courtesy SignaSys. Click here to see an enlarged diagram.
Multichannel operation means that the operations at master control must change fundamentally. Master control will become less of a real-time operation and will concentrate more on ensuring that the required program content is available as needed, along with the care and feeding of the various databases and logs that orchestrate the flow of programming on the various main and minor channels. To date, most multichannel operations keep a single, traditional master-control switcher, usually only for the main channel, and add router control along with downstream branding and EAS support to implement additional channels. Some operations allow the insertion of the traditional master-control switcher into minor channels as needed for more complicated event transition by surrounding the switcher by the router. In the future, master-control operations will be marked more by operations staff responding only to real-time events when last-minute changes occur or when problems or unusual issues arise.
To achieve increased functionality and the efficiency that multi-channel broadcasting promises, it is likely that more of the station's operation will have to come under an application layer, which will have to evolve from separate application islands into a single application “continent.” As such, satellite and other sources that are ingested into storage, along with a library system needed to track and manage that content, need to come under a common application layer. A library or other content-management system must accept external metadata or generate metadata itself to build the necessary tables in PSIP to augment the program services offered.
Next month, we'll look at why this new infrastructure might ensure your survival as a broadcaster. We'll also explore the forces that are compelling some broadcasters to try new business models to keep themselves relevant in the television content production-and-distribution business.
Jim Boston is senior director of technology and Mark Brown is CTO for SignaSys.
