Other articles from this series.

IP allows broadcasters to abstract away the media essence from the transport stream to deliver flexibility, scalability, and resilience. But in doing so, forces engineers to pay much more attention to the underlying network and transport stream. This is no trivial job, and the interconnectedness of modern networks demands an automated solution that allows engineers to focus on keeping the video and audio quality high while at the same time having access to tools that allow engineers to observe the system both at high and granular levels.

One of the most powerful aspects of moving to IP is that it allows broadcasters to separate the hardware from the software. Consequently, broadcasters have much more flexibility in how and where they operate their facilities. COTS and public cloud infrastructures provide an industry standard hardware base thus allowing broadcasters to concentrate on building flexible workflows that meet the needs of the business. The software-based components provide the ultimate in flexibility as they can be enabled or disabled as required. With modern public cloud and COTS infrastructures, all the broadcast media essence and support data can be processed including video, audio, ancillary data, control, and monitoring.

Although software processing is providing incredible opportunities for broadcasters, two challenges manifest themselves, these are human error and software bugs. With flexibility comes responsibility and just because an operator can change a parameter doesn’t mean they should, however, this is not always the case.

Building Flexibility

Modern broadcast facilities consist of many interconnected workflows that are often dynamic. Software processing goes a long way in simplifying the operation but there are still opportunities for operators to make mistakes. Often, these go unnoticed and don’t become apparent until downstream equipment has difficult decoding the video, audio, and metadata. And these types of errors can be difficult to detect and remedy.

Software infrastructures are providing broadcasters with massive opportunity for change, thus meeting the ever-demanding needs of the business. However, this places even greater pressure on the development teams which occasionally result in bugs entering the designs. This may not be due to coding issues but due to the potential for mistakes in the whole development process such as an incorrectly specified functionality. Although automated testing systems used by vendors as part of their deployment are progressing quickly, it still takes time to develop test vectors that can test the whole system exhaustively. Microservices have helped enormously with testing as small standalone programs can be tested in isolation leading to improved reliability. But the harsh truth is that software does occasionally contain bugs.

Agile development methodologies have driven software to a rapid deployment model where new features are released within a few weeks. This improves flexibility and delivers greater opportunities for broadcasters but does mean there is a constant risk of new bugs entering the software. Bugs should be thought of as a fact-of-life, not something we should get angry about. It’s fair to say that in the ideal world there would be no software bugs, but such an aspiration would mean development times would be shifted back into years, and not the weeks we’re now accustomed to. Essentially, we’re trading time with convenience and flexibility. And as in all things engineering, there is always a compromise.

One solution to this conundrum is to adapt our mindsets so that we expect bugs to exist and have strategies to deal with them when they manifest themselves. Continuous monitoring of both the audio and video essence, as well as the networks will help with this and in a way, this forms part of the agile mindset.

IP Network Complexities

SDI and AES networks had the advantage that they consisted of point-to-point connections that were relatively easy to understand, debug and verify. Just patch in a scope in one of the SDI segments and whether the segment works or not can be immediately seen. The bandwidths and latencies were well-defined leading to networks that were highly reliable, but static. It is possible to increase routing flexibility with these networks, but they are always limited to a few transport streams, such as HD-SDI and UHD-SDI.

IP networks deliver untold flexibility, not only with their topology choices, but also because IP packets are data agnostic. That is, the payload does not form an integral part of the underlying transport stream, unlike SDI and AES. Consequently, the IP packets can carry any data including media, monitoring and control information. The combined elements of multiple topology options and data agnostic packets form the true power, flexibility, and resilience of IP infrastructures.

However, these opportunities present new challenges in terms of interoperability. For an SDI infrastructure, due to the well specified standards from SMPTE, it’s often straight forward to work out the format of signal we are working with. Unfortunately, this is not the case with IP networks. Although ST2110 may have specified the media contents, we cannot be sure the IP stream we’re looking at is even carrying ST2110 data. It could equally likely be carrying monitoring information or control data. Even before we start looking at the essence, other issues arise at the network layer including packet dropping due to over subscription of a link, packet jitter, and even packets being sent in the wrong direction.

SDP And Essence

Session Description Protocol (SDP) files help alleviate this as they describe the format of data in a media stream. They describe such parameters as the video frame rate, image size, and source and destination IP addresses, to name but a few. SDP files help the broadcaster’s management system understand where the streams are in a network and the format of video and audio they are providing.

The management system or broadcast controller requests the SDP/essence information from a centralized registry (such as the NMOS registry) where all the devices such as the cameras, microphones, production switchers, and sound consoles etc. store and register their information.

Although SDP files prove incredibly helpful for system management, they can inadvertently contain errors due to either human error or software bugs. The main challenge occurs when the SDP file does not match the media essence due to an error in the video and audio workflow configuration. Modern broadcast facilities have potentially thousands of media essences with corresponding SDP files all moving from one stage to another in the workflow. For example, a transcoded media fill will generate a new SDP file, this file and the new transcoded media essence file(s) must be associated otherwise a mismatch will occur potentially leading to decoding errors in downstream equipment.

Essentially, when using these software components, the broadcaster has created a software defined workflow. Any software bugs or errors caused by misconfiguration within this workflow will cause the media essence that is either generated or manipulated by one of the processing stages to be out of specification. For example, a narrow-gapped ST2110 source device may develop excessive jitter due to a software bug which in effect will create a wide-gapped sender style, this will cause any downstream equipment expecting a narrow-gapped ST2110 essence to fail as the video buffers will be sized according to the SDP narrow-gapped information but will probably overflow due to the actual essence wide-gapped packets. The failure is therefore caused by the SDP vs essence mismatch.

To add to this challenge there are potentially thousands of video and audio signals traversing a network at any one time. If we think of a studio camera, this could easily have six input and output video feeds, possibly double that if we include SD and HD outputs. A production switcher may easily have a hundred input and outputs, especially if we consider the aux busses, international and clean feeds. And then there’s the multiviewers, as playout channels snowball, the number of multiviewer tiles must keep up. Audio has similar challenges and often surpasses the number of video streams.