Broadcast control systems have become a necessity to provide a unified and efficient user experience in a notoriously fast-paced environment involving IP edge devices and network infrastructures; baseband video routers and switchers; audio routers and mixing consoles; multiviewers; intercom systems, etc. Which system qualifies as the definitive “broadcast whisperer”?
Broadcasting professionals are expected to manage extraordinary complexity in real-time: switching sources, transferring control between studios and outside broadcast units, managing play-out, mixing sound and vision—and then some.
In a live production environment, nothing must go wrong. Never mind that time is constantly at a premium. In the light of budget constraints, doing more with less has become a given.
Given the variety of hardware and software solutions found in control and equipment rooms, OB trucks, studios and other locations, a streamlined user interface capable of triggering myriad automated routines and of routing streams has become as important as the gear and the network architecture themselves.
Leaving aside the fact that differing philosophies and physical/virtual control panel layouts on the manufacturer side tend to slow operators down, which in itself already justifies decoupling device operation from its proprietary user interface, the number of concurrent setting changes in a broadcast environment is overwhelming and simply cannot be performed in a split second by unassisted means.
By its very nature, a broadcast control system is a sophisticated one-touch remote control and automation system with a highly customizable look and feel.
Pressing a single button—whether on a hardware panel or on a touchscreen—triggers hundreds of complex routines, the overall result of which can be disconnecting one stadium from a control room at the broadcast center, or IBC, and reconnecting the latter to another arena instantly, and with all the routing and address changes that go with it.
In other instances, the control system is additionally used to reconfigure on-campus or remote workstation booths in response to the task the operator logging into the system (which could be via RFID) wishes to perform: editing, color correction, commentary, etc. This resource pooling usually only changes the software-controlled feature set of the devices inside the booth—the hardware stays the same. And we haven’t even touched on clustering routines that leverage the compute power of software-defined processing blades just about anywhere in the world.
Figure 1 - Complex systems can be easily configured and greatly simplified as can be seen with this VSM control panel.
Broadcast control systems have been around for a while and are able to control baseband, IP and hybrid (a mix of baseband and IP) infrastructures. As open-standards-based IP is in the process of becoming commonplace, operators are not just embracing the amazing potential and flexibility of sophisticated IP solutions—they start asking increasingly daring “What if” questions.
New workflow scenarios emerge as the complexity of broadcast campuses—whether “green field” or “upgrade”—literally skyrockets. A growing number of broadcasters and broadcast service providers already operate from different locations by default.
A provider of a highly customizable control system needs to be agile and open-minded to keep pace with evolving expectations. Most of these seem obvious and are easily explained, but fiendishly complex to implement once you get down to the nitty-gritty.
One example of a recently implemented evolutionary step is providing the ability to physically disconnect an IP-native device from one RJ45 or fiber-optic socket, connect it to another one elsewhere and immediately go on using that device without losing flow connectivity (a feature called “Wallboxing” in VSM speak). Users can even take advantage of an added “Trust Zone” feature, which allows operators to define the areas where Wallboxing will work for a given device to guard against undesirable side effects.
Another example is bridging two or more independent IP installs with a view to sharing (re)sources across networks, allowing one infrastructure to access selected sources of another infrastructure, for instance.
The overarching broadcast control system needs to function as an enabler for broadcasters, broadcast service providers, institutions and entertainment conglomerates that have chosen the IP protocol for reasons like unbridled creativity and efficient resource pooling.
Operators must be able to add more control features as expectations evolve. A cutting-edge broadcast control system therefore needs to be in a constant state of creative receptivity, which requires an experienced, international development team. Users in the US, Canada, Australia, Asia and Europe increasingly stray away from traditional workflows and happily explore the limits of what is technically feasible with IP.
Irrespective of the feature set, broadcasters expect a sleek, intuitive user interface, because most operators do not need to know where the streams and features being controlled originate and go, let alone what needs to happen to produce the expected result.
Scalability is equally important. Any broadcast control system worth its salt must support facility-wide IP infrastructure installs and be based on an architecture that has scalability in its DNA.
Cost is another consideration and turns out to be multifaceted (CAPEX versus OPEX). One important question to ask is whether the broadcast control system comes with an IP routing and orchestration layer or whether third-party hardware is required to deliver this service and make the controller fit for professional broadcast operation.
Finally, minimum latency is of the essence to ensure that all commands and settings reach their destinations in near-realtime.
And let’s not forget drivers for third-party devices, which should be available out of the box or else be supplied in due time by the development team behind the selected solution.
Putting It All Together
How about the configuration tool’s user-friendliness? What is important for the effective deployment of a broadcast control system and for ensuring that all features and services are not only available but also run exactly as expected? A solution based on a toolbox that focuses on simplicity and requires little training for TV engineers desirous to make occasional changes and additions, and/or to design their own user panels is bound to be a winner.
Drag-and-drop configuration based on standard windows is likely a must-have, as is the possibility to work with logical functions for swift implementation and massive signal-count applications. This should go hand in hand with access to a comprehensive overview of the entire infrastructure from one location and decent alarming routines.
Especially in large systems, time-efficient setup tools, like importing features from other panels (hardware or software user interfaces), cloning existing panels, and panel inheritance strategies help to save vast amounts of time. The same is true of efficient labeling routines.
The ability to configure small or large chunks of the overall solution offline, for its part, is invaluable for installs that require updates but need to stay online until everything is ready, and indeed for doing the necessary preparatory work in a different location.
Users furthermore expect all advertised features to be available “out of the box” rather than through intricate scripting and coding.
A sound user management strategy based on access credentials ensures that operators only have access to the functionality required for the job at hand. Access to the sensitive backend should be password-protected to avoid tampering.
Good looks and an intuitive, graphic user interface are welcome, of course, but should never be taken at face value: what appears to be intuitive at first glance often requires serious programming skills even for relatively minor changes.
The service offering of the control system’s vendor must not be underestimated either. A large configuration team ensures on-call availability and short lead times. And an open-minded—and sizeable—development team has the capacity to cater to special requests and to make the insights gained from such projects generally available as new version releases that benefit all users.
Also be sure to ask for the number of drivers and protocols available from the vendor and to solicit feedback from hardware and software vendors to find out how highly they rate compatibility of their products with the broadcast control system.
The emergence of IP-based broadcast networks allowing operators to station edge device where signals are generated and/or consumed means that networked devices essentially communicate with switches and no longer see where the streams are coming from or going. It is the broadcast control and orchestration solution that “glues” the equipment seamlessly together and provides a unified, intuitive control experience.
Several solutions are currently available. Making the right choice goes way beyond budget considerations. Experience has shown that the most important criteria are a shallow learning curve, vendor agility, support from a large third-party vendor base, a credential-based access strategy, fully redundant operation, and adequately staffed development and configuration teams on the vendor’s part.
Most stakeholders in the broadcast world are growing tired of aggressive claims and promises that cannot be substantiated any time soon (if ever). Look at the vendor’s install base, talk to existing users and find out where the shift towards IP-based control technology 2.0 is already underway. Then you should be ready to make a Very Smart Move.
You might also like...
Computer systems continue to dominate the landscape for broadcast innovation and the introduction of microservices is having a major impact on the way we think about software. This not only delivers improved productivity through more efficient workflow solutions for broadcasters,…
In the fourth and final part of this series, we wrap up with an explanation on how PTP is used to support SMPTE ST 2110 based services, we dive into timing constraints related to using COTS (Commercial Off-The-Shelf) hardware, i.e.:…
In the previous two parts of this four-part series, we covered the basic principles of PTP and explained how time transfer can be made highly reliable using both the inherent methods IEE1588 provides as well as various complementing redundancy technologies.…
In the first part of this four-part series we described the basic principles of the Precision Time Protocol. In part two, we investigate PTP redundancy, specifically for media networks.
As the broadcasting industry is moving from a traditional SDI infrastructure towards the All-IP Studio providing a common frequency and – equally important – an absolute notion of time for all devices is now provided by the underlying infrastructure itself. In this fou…