The Liberation Of Broadcast Technology - Part 2
Building optimized systems that scale to meet peak demand delivers broadcast facilities that are orders of magnitude more efficient than their static predecessors. In part 2 of this series, we investigate how this can be achieved.
Studios, graphics, playout and master control have all historically been designed to do one specific job. The equipment and infrastructure have been built to meet the peak requirements, but the peak demand is rarely met. For example, a studio with a multiviewer would normally have a dedicated multiviewer hardware solution providing the functionality. However, despite the best efforts of schedulers, the hardware may only be in use for a few hours a day. It’s likely that the studio wouldn’t be in use overnight.
Although this is a fairly simple example, it does demonstrate the inefficient use of high value hardware in a broadcast facility. Furthermore, this “waste” may be replicated many times throughout the facility as systems are designed to deliver for peak demand.
A single software version makes available multiple functionality that is released by vendor issued keys.
Peak Demand Optimization
Learning from the IT industry, broadcasters can see how virtualization is used to provide the best of all worlds. Peak demand is still met as virtualized servers can be spun up and deleted as needed but the hardware usage is spread over the whole facility.
Flexible licensing further expands on the virtualized model. Pools of licenses are made available to system administrators so that individual licenses can be deployed as and when needed. This concept is even more powerful when we consider the deployment of a single code instance that contains multiple functions such as a multiviewer, analysis probes and production switchers.
It might be that the data throughput of a function is so high that a particular application does not lend itself well to virtualization and so dedicated servers must be used. Even with this model, the server can multi-task and with the correct code can provide many different functions. Although the server may be located in a specific location within a facility, through high-speed networks and flexible licensing, its physical location and application have essentially been separated, thus allowing it to be “moved” not only to different studios within the facility, but also used for different applications.
Code Centralization
Installing the code on a server is much easier than the traditional methods of software maintenance. As only one version of the code is required, it may well be installed on a centralized server and loaded locally onto the application server when it is enabled. This greatly simplifies software maintenance as only one version of the code needs to be installed.
A broadcaster may purchase a thousand or more licenses and make them centrally available. As the license is effectively a computer file, it may be deployed by an automation system. This opens up a whole new load of opportunities for broadcasters looking for ever greater efficiency improvements.
Software Configuration
With the correct COTS server farms and associated high speed networks, the whole infrastructure could be abstracted to a fully flexible software-as-a-service solution (SaaS). The granularity of control could be as varied as the broadcaster requires. In the extreme, specific TV- shows can be programmed and made available through a scheduling system.
Flexible licensing empowers broadcasters to make the best of dynamic systems and fully optimize their use. The speed with which agile development makes new features available is breathtaking and the single code model further improves efficiencies and flexibility as a common version of the code can be deployed over many servers.
To build efficient infrastructures, broadcast engineers and administrators need to start thinking in more abstract and flexible terms. The traditional rigid peak demand broadcast infrastructures of the past are now history and to gain the efficiencies COTS promises, we must look to exploit dynamic systems wherever possible. Flexible licensing and single-code deployments deliver this.
Supported by
Broadcast Bridge Survey
You might also like...
IP Security For Broadcasters: Part 1 - Psychology Of Security
As engineers and technologists, it’s easy to become bogged down in the technical solutions that maintain high levels of computer security, but the first port of call in designing any secure system should be to consider the user and t…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…