In this series I speak to senior industry figures who’ve had the opportunity to either build IP networks or who are in the planning stages of major infrastructure projects.

We interviewed three guests and contributions from each of them feature in all three 30 min episodes:

Geir Bordalen, Head of Technology Portfolio at the Norwegian Broadcast Corporation - is in the early planning stages of building a green-field IP broadcast facility.

Paul Markham, Global Technology and Operations Director, and Media Infrastructure Architect for Discovery - discusses broadcast infrastructures from the software perspective.

Dave Schwarz, Managing Engineer for Diversified - has more IP infrastructures under his belt than any of us would care to imagine. Dave discusses the hardware infrastructure and what it means to build IP. 

Part 1: Initial Planning & Scoping (CLICK HERE TO WATCH) - looks at the initial planning stages for a major infrastructure project, software development and mindset changes, and specifying switchers for IP.

Part 2: Practical Topologies and Systems (CLICK HERE TO WATCH) - discusses the practical aspects of building IP infrastructures, the architecture topologies considered during planning, the philosophy & benefits of Agile Development, and making IP systems flexible, scalable and resilient.

Part 3: Delivering Operational Reliability (CLICK HERE TO WATCH) - discusses the merits of cloud, datacentre architectures, the crucial role of logging in maintaining system reliability with software infrastructure, and the potential use of compression to deliver increased efficiency and economy.

About Part 3 - Delivering Operational Reliability

In the previous two recordings in this series about transitioning to broadcast IP infrastructures, we looked at the initial planning and scoping, and then the topologies used. As the IP infrastructure develops, we now turn our attention to operating and maintaining the system to achieve operational reliability.

Monitoring is at the core of all broadcast systems and it is usually one of the engineering aspects of the design we consider first. Waveform monitors, vectorscopes and audio monitoring have been with us since the very first days of television, but with the addition of IP we now must consider new methods of monitoring the packet switched data.

In traditional circuit switched SDI networks, it was generally enough to know whether a signal had reached its destination through the point-to-point connectivity as its journey was well defined. But as we move to packet switched IP then there’s a whole load of other information we need to monitor. This isn’t limited to just the data integrity but the timing and system configuration too.

Data logging helps us understand what has happened as well as what could happen in the future. The massive amount of data distributed over multiple networks can make monitoring difficult but recording data and then analyzing it later on will give us greater insight to the dynamics of the network.

One of the often unsung benefits of IP is that it has opened the doors to software and infrastructure as a service. Servers can be spun up, and spun down, and large parts of the network can be reconfigured through software control. But this flexibility needs to have a close eye kept on it as we can’t see, hear or feel the system. Real time monitoring is our true connection with the efficiency with which it is operating. Again, Agile mindsets help us enormously with this methodology.

Whether to integrate into the cloud or not is another decision that greatly influences workflows. The lure of massive amounts of storage and processing power must be balanced with accessibility and the cost of ingress and egress. How we monitor usage, network bandwidths and download speeds greatly affects the operation and our approach to resilience so we can anticipate problems before they occur.

Many see cloud computing as the way forward. The availability of a massive resource at the touch of a button, and the dynamic software configurability all contribute to the attractiveness of the cloud. But integrating it into a fully operational broadcast infrastructure requires much planning and detailed design.

Should we compress video and audio or not? This is a question that is at the forefront of many engineer’s thoughts. There are many good reasons to compress the media to improve distribution and reduce network bandwidth, but this comes at a quality price. Or at least that’s what we’ve always believed.

A completely new class of visually lossless video compression has appeared that is taking the broadcast world by storm. Is it possible that even after concatenation, the quality of this compression will meet the needs of broadcast television? And where is compression already used in broadcast equipment? Maybe we’re fixating on a historical quality issue that is now out of date?

Latency has been a subject of great discussion in IP circles for some time. But as IT infrastructure equipment improves and processing speeds increase, do we still need to be concerned with latency? How much is too much? And how little is acceptable?