As the IP revolution continues to transform media and broadcast and deliver greater efficiencies and flexibility, prompting will be a key beneficiary, especially when it comes to smooth, instant failover in the event of an equipment glitch. In this article, we’ll look at the impact of IP networks on prompting redundancy and reliability.
Teleprompting is the unsung hero in the broadcast chain – a critical essential, to be sure, but one that’s often taken for granted until it doesn’t work. As one of our customers said once, “Prompting is one of the last things that broadcasters think of, but it’s the first thing that’s missed when it doesn’t operate properly.”
As the IP revolution continues to transform media and broadcast and deliver greater efficiencies and flexibility, prompting will be a key beneficiary, especially when it comes to smooth, instant failover in the event of an equipment glitch. In this article, we’ll look at the impact of IP networks on prompting redundancy and reliability.
Room for improvement
To appreciate what’s at stake with prompting reliability, consider the talent’s position. For a news anchor or other media personality, there are fewer worse nightmares than a prompter that stops working on air and a script that disappears mid-read. Pre-IP, getting things going again has been primarily a manual and delay-filled process often requiring engineering intervention.
Traditional prompting systems rely on USB, serial, or video cables to connect the controllers to a local prompting engine and video connections to deliver the prompting output to a traditional on-camera teleprompter monitor. For critical live productions, even the most resilient of these systems requires a second, completely redundant computer and video generation unit running all of the same settings as the main unit, such as the presenter’s choice of font sizes, background colours, newsroom connections, loaded rundowns, or controller profiles. In the event of a problem on the main prompting computer, an operator has to manually fail over to the second box using an A/B switch.
Since the two systems aren’t automatically synchronised, the operator has to manually locate the correct place in the script on the redundant system. Controllers also have to be duplicated or separately switched with a second A/B switch, and the switchover of the video causes the prompting monitors to lose their input and cycle for a signal, creating further delay. In the meantime, the talent is forced to improvise while enduring second after appalling second of missing script.
IP networks: built-in redundancy
In contrast, an IP-based prompting workflow creates connectivity without requiring point-to-point connections, and therefore delivers core redundancy. At the prompting application level, this enables a full-redundancy fail-safe by which a mirrored PC, paired with the main application, can seamlessly take over if the first PC/application fails — with automatic synchronization of script position, individual users’ settings, controllers, newsroom connections, teleprompters, etc. When the first application recovers, it drops into standby mode, at the ready should the active PC fail.
Since all elements of the prompting system are networked devices and therefore not physically connected to each other, the existing controller(s) can continue working with prompts from the backup machine, wherever it is in the world. Because the switch from the host PC to the backup is immediate, the on-air talent might notice nothing more than a fractional, millisecond pause in the scroll speed – if he or she notices anything at all.
A critical element: data-only transport
Delivering and displaying the video script on the prompting monitors is another area that is vastly improved in an IP-based workflow. Traditional prompting systems send a full video feed to the monitor via a video cable; likewise, some approaches to IP prompting send the full video signal over the network. While video over IP might work well for many other types of IP media deployments, it’s not ideal for prompting because of bandwidth issues (requiring compression, encoding and decoding) and the potential for latency and synchronisation problems.
A better approach – and one more conducive to reliability – is for the prompting software to send small unicast data packets instead of the full video feed. With only small amounts of data sent over the IP network, every monitor can remain in constant communication with the master application to ensure reliable synchronisation and centralised management. Rather than all monitors relying on a single video stream from a video generator – a single point of failure – each monitor on the network renders its own script video. The prompt operator can see at a glance the status of all devices, be they scroll controllers or on camera monitors, and so can tell immediately if there is any issue.
Building redundancy into an IP-based prompting network
So what are the vital elements of an IP prompting system that delivers these levels of reliability? First and foremost, the solution requires software that offers a fully synchronised redundancy system with mirror functionality. (At this writing, WinPlus-IP from Autoscript is the only software to offer these capabilities.) Also critical are prompting monitors with built-in intelligent scroll technology that enables them to generate a script independently, based on the data packets sent over the IP network. All IP-connected devices, including controllers and prompters, need to be able to be seamlessly managed by the device manager of any application on the network.
Although creating IP prompting redundancy requires two software applications, the days of having to duplicate hardware for the scroll engine and controllers are over. The benefit of this comes into focus with a prompting workflow that enables broadcast operations to collaborate across geographies and allocate resources cost-effectively. Since the software-based prompting elements are connected on a network rather than running on local hardware, the backup PC could be in a different time zone that isn’t operational. As any operator can prompt to any teleprompter on the network, an operator in New York can control the script, speed, and other prompting attributes of a prompter in London and instantly switch control to an operator in Doha in the event of a resource issue, such as operator illness.
It all comes back to the talent. In the final analysis, the anchor or other on-air personality doesn’t care how the scripts are delivered; he or she just wants to be able to read the text at a comfortable and adjustable pace, with no hiccups or interruptions. For an IP-based teleprompting solution, the right built-in intelligence creates failsafe reliability and a win-win situation: talent is enabled, rather than hindered, by the technology, and the broadcast operation is able to take maximum advantage of IP’s connectivity, flexibility, ease of use, and cost efficiencies.
