The new playout facilities at Turner Broadcast System in London feature Pro-Bel automation.
Broadcast automation has been with us for many years now, and it has evolved rapidly. Many broadcasters are now on their second or third generation of products and have experienced the “joy” of rolling out these ever more complex software systems.
Stages of broadcast automation
As facilities move forward, there are several more changes through which the industry must transition. Let's examine them briefly.
Broadcast automation can broadly be categorized into a series of three generations:
- Tape: The challenge of early automation was to reliably and frame-accurately synchronize multiple devices in order to play out a schedule. This generation culminated in large cart machines typified by the Sony LMS.
- Tape/server hybrid: With the advent of video servers in the mid-1990s, broadcasters moved to hybrid playback systems, with short-form material played from servers and long-form material still played from tape. The reason for the hybrid approach was that servers were still too expensive to be used for long-format content. The advent of video servers also required new management software to track the many files across servers.
- Tapeless: Many current automation projects are now focused on moving to entirely tapeless workflows. With this approach, the content is usually delivered electronically direct to playout systems, typically from a satellite ingest platform.
Of course, this view of broadcast automation as represented by three generations of technology is a bit of over-simplification. The reality is that all of the above required that many other device control issues be addressed throughout the playout process — from master control and graphics through to closed captioning and other ancillary data streams.
The automation of many of these devices has introduced the requirement to play out events in parallel, commonly referred to as secondary events. A simple example might be control of a downstream keyer during a program to turn a station logo on and off. Whilst we're still solving the issues of changing to a tapeless operation, additional demands are appearing.
Pro-Bel’s Morpheus automation system is designed to handle simple server playout to complex channels where schedules are changing regularly and unpredictably.. Click here to see an enlarged diagram.
The first new area of complexity is the ever-increasing amount of data that has to be transmitted along with the basic picture and sound. Typically, this means closed captioning and audio descriptions.
Another new requirement for broadcasters involves the transmission of metadata for interactive applications that execute on a set-top box. Finally, broadcasters are no longer one-channel operations. Many stations will find themselves having to handle multiple feeds, often with no additional staff. This trend will certainly continue as broadcasters provide services to mobile devices and begin using new delivery platforms such as IP.
All these factors mean that as the number of services increases, there is a greater need to repurpose content. Ideally, an automation and media management solution should be able to air different versions of a program, possibly with different graphics and captioning, all from a single master copy without the need to manually create custom versions.
Possibly the biggest issue is that there is no clear picture of what the broadcast world of tomorrow will look like. Therefore, the challenge today when looking at a fourth-generation automation system is not knowing exactly what it is going to have to automate, and how, over its lifetime.
True multimedia
Even with this major challenge, it is possible to identify some key attributes that should be considered in a future automation system that could meet the challenges described above.
Multimedia is a highly overused and often misused word, but we need to consider it in its purest form. For our fourth-generation automation system, we need a solution that is media agnostic, i.e. not tied to 25fps/625 or any other standard, for that matter.
The schedule
Arguably, we are not talking about a future requirement but one that is here today. Media has to be delivered in many different resolutions and frame rates; the days of working to one dominant standard such as PAL or NTSC are over. Our proposed new automation system needs to handle multiple video standards, including future ones. And in a multichannel or multi-stream environment, the automation system has to be able to work with different standards on different services simultaneously.
Traditionally, schedules have taken the form of flat files that describe a linear sequence of events, often with some capability for describing secondary event functions such as DSKs. For the types of applications that have been outlined, more scalable and flexible schedules will be required. The core scheduling criteria can be summarized as follows:
- Ability to describe unlimited event properties. This means that file format cannot be fixed to specific event parameters that were defined in the original system.
- Ability to describe unlimited secondary events, and for those secondary events to be hierarchically grouped.
Fortunately, we already have an ideal tool that meets these requirements — XML. This is the same XML code that originated in the Internet development community, and it allows self-described data to be transferred between systems. Let's look at an example of how this might work. We will use a simple schedule example. Here is how a typical event would be described with a simple ASCII string:
0001,Coke Ad,1000000,00003000.
In this example, the event number is 0001, the title is Coke Ad, the in point is 10:00:00:00, and the duration is 00:00:30:00. To understand this, both the system that authored the schedule (traffic) and the receiving system (playout automation) need to speak the exact same language — labels, variable order, etc. In XML, the same event could be described as:
0001
Coke Ad
10:00:00:00
00:00:30:00
Consolidating information
Whilst the full capabilities of XML are beyond the scope of this paper (see Ref. 1 on page 47 for a good tutorial), the key points to note are how each piece of data is described and how the data can be grouped hierarchically. These two characteristics will allow the most complex of schedules to be described.
Conceptually, automation is a simple product. It is a software program that executes a list of events, each one controlling a machine that will air a television program. However, as with many concepts, the complexity lies in dealing with the unexpected. For example, what happens when a tape doesn't cue or when there is a last-minute change to the transmission schedule?
Automation systems can have automatic responses to a number of anticipated failure conditions. However, many conditions will need a subjective judgment that is beyond the scope of an automated process. This means that clear status information for events must be presented to allow appropriate action. However, with the increase in numbers of both channels and secondary events, effectively summarizing large quantities of event status for a single operator will soon become an issue.
Intelligent monitoring
Status information requires consolidation, as reporting the ‘raw’ status of many hundreds of events will just result in information overload. Being able to integrate status for logical groups of events will be essential in live broadcast environments.
Another aspect of information overload is when an operator has to monitor the final output of multiple services, as well as the off-air pictures. Keep in mind that with future systems, the term off-air may not be an accurate description of the delivery channel.
System resilience
Automation systems will increasingly have to integrate and accept data from automated monitoring systems. No longer will it be sufficient for the automation system to report only if a device fails to roll and then rely on a human operator to intervene. End-to-end solutions that can reconcile the signal from ingest through transmission (in whatever form) will be required.
Of course, for any automation system, the reliability of on-air playout is of primary importance. One approach to this reliability is through dual redundancy, both in terms of automation system components and control peripheral devices. Unfortunately, with an increasing number of channels, having two of everything ceases to be a viable economic model. The N+1 or N+X resilience models are becoming more the norm, where systems providing N channels of playout have additional capacity that can be switched in in the event of failure.
Standardization of automation systems, interoperability between devices, is vital. Therefore, the adoption of workable standards is essential. As we have seen, the number and types of devices that an automation system has to interface to is multiplying; hence, the development of workable standards will become key, but this comes with a health warning.
Program and System Information Protocol, PSIP (see Ref. 2), is a standard protocol that defines data in a digital transmission. A flexible automation system will allow PSIP data to be attached to events in the schedule. The requirement for DTV metadata is likely to be an increasing one, and the addition of other types of delivery channels will bring new standards and data that need to be supported by the automation platform
Currently, XML is being used as the basis for many protocol standards. Unfortunately, despite all its benefits, a tool such as XML will not guarantee compatibility between systems. As we're seeing, even when a hugely powerful and important industry-specific standard such as MXF (see Ref. 3) is defined, that does not ensure absolute interoperability.
The MXF language uses XML and is analogous to its core principals in that it provides a mechanism for metadata. The language does well in describing a piece of media to be combined in a single file with the media. This allows the media to be exchanged between two systems and understood by the receiving system. But just as with XML, the use of MXF does not ensure interoperability. It is perfectly possible and completely valid to define two incompatible MXF schemas. As an example, the metadata required in post-production is different from that required in master control. Such issues need to be considered early in the planning of a master control operation.
An evolving solution
Adherence to standards will be key for an automation system, but this alone will not alleviate the need for detailed system and workflow planning to ensure workable solutions.
Broadcast automation has been, and continues to be, an evolving technology. Developing solutions for our immediate future presents many challenges. From this vantage, the simple requirements our future automation systems must meet is that of complete and unlimited flexibility. Now that's a tall challenge.
References:
Neil Maycock is chief technology officer for Pro-Bel.
- W3 Schools: www.w3schools.com/xml
- PSIP: Program and System Information Protocol: www.psip.org
- MXF: Media Exchange Format: www.smpte.org
