Services Global Viewpoint – December 2020

Closed systems should be incredibly secure and robust, and mostly they are, but the price we then pay is resistance to change. Vendors have done their best to keep up with broadcaster demands, but it’s almost impossible to provide proprietary interfaces that deliver all the flexibility and connectivity modern infrastructures demand.

One of the challenges of transitioning to IP is that ST2110 really only gives us a bare-bones media distribution system. There’s no plug-and-play, device registration or simple connectivity as parameters values such as frame rates and color space aren’t available to terminal devices. Instead, we rely on protocols such as NMOS to provide these functions.

The pace with which broadcast technology is advancing is breath taking, especially with the pressures COVID-19 has placed on remote working in recent months. In the days when television used to work at a more sedentary speed, change was much more manageable. The main contributor to this speed limitation was that most of our infrastructure was built in hardware. Design cycles for even the simplest hardware design can run into weeks and even months, seemingly growing exponentially as the signal clock frequency increases.

Although there is much commonality in core infrastructure designs, such as the need for cameras, microphones, production switchers and sound consoles, almost every broadcaster builds their workflows with different objectives. These complex design criteria soon shout for flexibility.

Software is the ultimate in resilience and provides us with any control interface we could ever wish for. But this is where the challenges arise. Just because we can do something doesn’t always mean we should. It’s almost as if software provides us with so much choice that we find it difficult to make decisions, especially when designing interfaces.

SDKs have been a common way forward as they provide the advantages of a working interface while encapsulating and hiding the underlying complexity. In most cases this is probably a great benefit as any software developer will welcome consistency and reliability when writing code to integrate workflows. But there will always be a need to connect systems together in a way that wasn’t originally envisaged, and this is where open systems, including open-source software, will always benefit us.

However, taking ownership of the source-code now puts you in a position of great responsibility. As soon as you start developing your own implementations such as interfaces, you have to fork away from the original software design. What happens next? Do you try and merge your changes back into the core repository? Or do you forever move away and keep your own version separate to the community development? And if you do, what happens when there’s a security patch in the core? How do you resolve this into your fork?

Open-source systems seem like they are the answer to all our dreams, they offer the ultimate in flexibility and we can tweak and change them to our hearts content. We can design interfaces to do anything we want and customize beyond belief. But open-source code needs more maintenance than we could probably imagine, and this should be thought through. Maybe this is where forward thinking vendors can find new opportunities and work with broadcasters to find optimal solutions?