The Liberation Of Broadcast Technology - Part 1
For many years broadcasters have been working with static systems that are difficult to change and upgrade. This two part series explores the unfolding of a more elastic future based on COTS hardware and flexible licensing.
The static nature of infrastructures has been imposed on broadcasters due to the technical demands digital video in particular places on distribution. But these limits also manifest themselves in audio infrastructures. The human hearing system is incredibly sensitive to the smallest audio distortion so networks must be incredibly reliable as we can’t afford to drop even one packet of audio.
Up to recently, the video and audio networks were dedicated infrastructures based on SDI and AES. The speed improvements COTS infrastructures have now delivered are transforming both the way we distribute video and audio, and also how we process it.
It’s almost impossible to keep a studio running 24/7. Even if we allow other studios to use key equipment such as the production switcher or sound console, the nature of television means that resource demand is very peaky. Consequently, broadcasters must plan for the maximum peak demand, often leaving expensive infrastructure devices unused for large periods of the day and night.
Moving to COTS hardware infrastructures helped solve some of these challenges as the equipment tends to be more affordable and has less customization. The unique nature of SDI and AES requires hardware interfaces that are specific to the operation of each device in the video and audio processing and distribution chain. SMPTEs ST-2110 and ST-2022 suite of protocols helped solve many of these challenges as they removed the need for a custom interface such as those required for SDI and AES, replacing them with more commonly available Ethernet interfaces.
One of the key advantages of COTS infrastructures, other than the fact that it has a greater reach in industry and is therefore more readily available, is the software that runs on it. The processing speed and data throughput of COTS hardware means we can now run software that can reliably process video and audio in real-time. Software packages providing a whole host of functionality is now available on a common platform to further improve resource utilization.
Building on this, flexible software licenses are now ready to enable or disable functionality within a single software distribution. These licenses further improve flexibility as they can be purchased on a pay-as-you-go basis. This improves on standard software installations as a global version of the code can be installed leaving its functionality to be enabled as required by the software licensing.
Software defined studios are now within our grasp as we progress beyond COTS infrastructures to global software and flexible licensing. This Essential Guide discusses the need for flexible licensing, how it works, and a hint at some of the new flexible working practices now available to us.
Recent developments in IT systems has seen COTS infrastructure not only meet the demands of broadcasting, but also exceed it. High performance computing and ISP grade ethernet switches have all contributed to making IT work for broadcasters. Another revolution is taking place - the adoption of flexible and floatable software licenses and the business models that finally allow broadcasters to maximize asset utilization. In these articles we investigate this phenomenon, and the advantages flexible and floating software provides for broadcasters.
One of the great advantages of software is that Agile development cycles are incredibly short and continuous when compared to the traditional Waterfall method. Agile practices focus development teams on delivering operational features as they are needed - resulting in software that meets the never-ending demands of the user. Alternative Waterfall methods of project management result in code being delivered that is often out of date and provided many months or years after the first product concept is delivered.
Broadcast hardware is traditionally custom by design. In part, this is a necessity as the relentless video streams take electronic designs to their limits to deliver the video bit rates needed to give us fluidity of motion and vibrant colors. This equipment is so specialized that it is almost impossible to repurpose and often goes out of date soon after it is installed.
Better Hardware Utilization
Utilization of broadcast hardware is quite limited as each device in the program chain can generally do one specific job and this is often within very fixed parameters. For example, the scaler and splitter hardware used for a multiviewer uses very specific dedicated hardware and is limited to that particular function.
Developments in High Performance Computing have succeeded in taking COTS computer hardware to unprecedented performance levels. Not only does high performance COTS equipment meet the requirements of processing real-time video but it often exceeds it.
This all leads to a change in the way broadcasters can now work but it does demand a new mindset. Instead of building systems using dedicated hardware components with fixed point- to-point networks that culminate in high costs and static systems, we should be looking to COTS hardware and flexible licensing as we can have clusters of hardware that provide a solid platform for real-time video processing in software. The ultimate flexible experience.
Software Management
Maintaining software is often a challenging and difficult task. Technically it should be very easy as vendors have made applications that will copy the relevant files and delete any old ones. It’s often the administration of software maintenance and the associated versioning control that makes the job difficult.
Having one version of the code that provides many features helps with this task enormously as there is only one installation to update. Although the code still needs to be uploaded and installed, having just one version that provides many different functions that can be enabled through flexible key control, simplifies the task completely.
Change Control
ITIL (Information Technology Infrastructure Library) processes used by professional IT departments require change management. In its simplest form, this is a document that highlights a change control, such as a software upgrade, that requires all users of the service to agree to and sign up to. This alone can cause incredible delays and will often outweigh the benefits gained by Agile development. Furthermore, there is often appreciable downtime for integration testing and verification.
Agile development has traditionally lent itself well to web-server type products. Using virtualization and load balancers, web servers can be updated on-the-fly so that there is no perceivable loss of service to the user.
More recently, this methodology has become available to general applications through the use of distributed code and flexible licensing. The core software must be built to support this, but essentially, single release provides all the functionality offered by the vendor and each function and feature is released by the licensing key.
Functionality Distribution
Working on COTS hardware and within a well-defined software structure and environment, vendors can make a whole host of licensed functionality available to broadcasters. The functionality can be exhaustively tested during the development phase meaning they are bug free when made available to the broadcaster.
Each server has a copy of the same code and from a central repository providing the complete software deployment. The features are easily available as they are disabled until the unique keys are entered into the core software to enable them. This further enhances code compatibility across multiple clients making versioning much easier for the vendor to administer which in turn will make the code more reliable.
Furthermore, the keys can be enabled and disabled as required and can even be time referenced so they only provide a given functionality for a specific length of time.
Workflow Requirements
Vendors and broadcasters are often at the two ends of a tug of war. The vendors want to provide as few versions of the code as possible to both improve efficiencies and reliability. And the broadcasters, with their unique workflows want to make the code as unique as possible to meet the specific requirements of their facility.
Flexible code licensing provides solutions for both vendors and broadcasters as the licensing key is designed to enable features for specific broadcasters. For example, one broadcaster might want their multiviewer instance to provide error detection reports using XML files and another broadcaster might want to provide the same reports using JSON files. The same code will provide both of these solutions but only one option is available to each broadcaster through key management.
However, this philosophy can go far beyond simple versioning control and feature availability as entire applications can be managed. Again, one version of the code is available, but many features and functions are distributed in the code waiting to be unlocked. The same version of code may include a multiviewer, analyzer probe and production switcher, and the keys provided by the vendors enable the feature purchased.
Keys can be distributed from the cloud as well as centralized servers. This greatly improves flexibility for broadcasters allowing them to dynamically allocate resource to build systems quickly and on-the-fly.
COTS Stability
The key here is to remember that the whole code runs on COTS hardware, so many assumptions about the underlying hardware can be made by the vendor. A minimum specification must be defined, but the vendor will test their code on a known hardware platform to further improve reliability.
Distributing one version of the code to all broadcasters drastically improves reliability. One of the challenges vendors have is understanding and testing for all the different permutations and combinations of code and client specific requirements. If these can be better understood, then the vendor has a better chance of providing reliable software testing.
This reliability is further improved through the specification of hardware. COTS is an all-embracing term that can cover many hardware specifications and these need to be well defined. But this is nothing new, high performance computing has been working like this for a long time.
Flexible licensing combined with a single version of code also provides the concept of peak demand optimization for complete broadcast infrastructures. As licenses release the features of the code on a per license basis, system administrators can choose how, where and when to deploy the individual product features in the code.
Dynamic Systems
To truly benefit from COTS infrastructures, broadcasters must employ dynamic systems. Through virtualization, servers can be spun up or deleted as and when required. Traditionally, broadcast infrastructures have been built to meet peak demand and this is one of the reasons they are so expensive and rigid.
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,…