System Integrators—What Value Do They Bring To A Project?

Historically, the value System Integrators (SI) brought to a project centered on providing specialist broadcast, video and audio expertise and knowledge. But as more installations become a mixture of servers, databases and web browsers, today’s system integrator must adapt to support the new demands of IT-centric hybrid broadcast systems.

Manufacturers are more than willing to provide technical assistance during specification and installation. Supplying their own support engineers on site during critical parts of the installation means the broadcaster has access to cutting edge knowledge and expertise of that particular product, whether it’s a vision mixer, sound desk or graphics kit.

However, when the manufacturer's engineers return to their factory, the broadcaster or production house is left to resolve remaining issues by itself. That may be a good time to see additional help from an SI.

Instead of soldering irons and BNC’s today's video engineers must now work with configuration files and network analysers. Broadcast engineers need to understand Cisco networks, Linux file systems and be able to install and support multiple SQL databases.

The fundamental difference between IT and broadcast engineers is one of attitude to time. An IT engineer will sacrifice the time it takes to deliver a data packet at the expense of having no corruption or loss, they assume the network will have some errors and will implement protocols such as TCP to overcome them. A broadcast engineer assumes the network is robust and solid and there is no packet loss, in live productions we do not have the option of resending frames of video.

The network is key

IT Networks are renowned for being complex. Not necessarily due to the amount of equipment involved such as routers and switches, but more to do with how they are configured. From the broadcast engineers’ point of view, the architecture and design often defies logic as the network splits the physical underlying connections from the routing and protocols using the ISO seven-layer model.

IT architecture provides a general “one size fits all” solution for enterprise IT and broadcast. This can often be a problem for broadcast engineers as they think more about connectivity of point-to-point signal paths and dedicated routes as opposed to self-learning networks. For example, A-B SDI switches provide resilience through main-backup signal paths.

Network configurations are based on rigid vendor specific design models and rules, and network architects will stay with one vendor for most, if not all of their career. New innovation by vendors such as Cisco are built on existing designs so their army of accredited network engineers can easily learn the new systems and promote them to their clients.

Broadcasters generally need two levels of functionality from an IT network; control of equipment such as a vision mixer or camera, and video/audio over IP delivery. Both of these are time critical and require solutions that separate the networks from each other, and from the enterprise office IT system. Further safeguards must be put in place so that spanning tree protocols (STP) do not affect the broadcast network as resetting the routes can result in a network outage of twenty or thirty seconds.

Modern SI’s know all of this and have suffered the pain and learned the lessons of network outages on infrastructures of early adopters. IT engineers regularly re-patch equipment which could inadvertently cause a layer 2 network loop resulting in a spanning tree induced outage. This approach is unacceptable for broadcasters. SI’s know this and one of the key benefits they bring is to bridge not just the knowledge gap, but also the differing attitudes and cultural experiences between IT and broadcast engineers.

IT Turf wars

IT and broadcast engineers are highly experienced and disciplined in their own fields. However, the time taken for a network engineer to understand the intricacies of broadcast will take many months, if not years of training and practical experience. And it’s the network engineer who must move into the broadcasters’ domain of understanding as television systems are so time critical in their operation and implementation. We can’t just drop a few frames of video, or have the sound desk faders lag the level controls in the DSP rack by 20mSecs, or have a twenty second network outage during the Super Bowl or Wimbledon final because somebody has just incorrectly re-patched the office printer.

Open source software has provided freedom for engineers as they are not tied to a specific vendor for their operating systems, storage or transcoding. Broadcast engineers are renowned for being innovative and finding solutions to problems, and the thought of having source code they can upgrade themselves, install, or even reprogram appeals greatly. However, the reality of the situation is quite different.

Anybody who has installed open source operating systems or FTP programs knows the process can take a great deal of time and be incredibly frustrating. Open Source software often relies on having to install numerous dependent libraries of specific versions, often executables are not available so you have to compile the source code yourself. The benefits of Open Source software soon start to wane as the reality of enterprise level installation becomes apparent. Even installing vendor specific hardware has its challenges as you may need to install multiple connected databases to leverage all of the features.

Much of the broadcast kit in production has been designed by engineers who’s roots are in television, so they think in a broadcast way. Quite often we find this restricts us in being able to fully leverage consumer off the shelf (COTS) advantages as the vendor has inadvertently designed their product in a slightly quirky manner.

SI’s have many years’ experience using open source software and know the pitfalls and dependencies that may occur during installation. This means they can generally deliver a working system quickly and reliably. Often these companies have on-staff programmers who can write scripts and interface code to make different vendors systems work together to achieve better automation.

When commissioning a new system, Chief Engineers now have an added level of complexity to consider. This requires them to carefully analyse and understand the risks involved in delivering an in-house design. On the face of it they probably have the necessary skillsets in their IT and broadcast departments. However, achieving a mutual understanding between the two may be difficult due to the historical cultural differences and their respective disciplines. And delivering enterprise level open source software solutions is a million miles away from installing Linux on a home PC. Successful SI’s continue to solve these problems and reduce risks to deliver enterprise level solutions.

You might also like...

PTP V2.1 – New Security & Monitoring For IP Broadcast Infrastructures - Part 2

In the last article in this series, we looked at how PTP V2.1 has improved security. In this part, we investigate how robustness and monitoring is further improved to provide resilient and accurate network timing.

PTP V2.1 – New Security & Monitoring For IP Broadcast Infrastructures - Part 1

Timing accuracy has been a fundamental component of broadcast infrastructures for as long as we’ve transmitted television pictures and sound. The time invariant nature of frame sampling still requires us to provide timing references with sub microsecond accuracy.

Creative Audio - Noise Reduction With Bob Bronow

Dialogue is king in television. Let’s face it, you don’t watch an episode of your favorite police procedural or reality show just to listen to the sound design or the incidental music. But whether the content is scripted or …

Creative Audio - Broadcast Crowd Sound

When televised sports events began to return after the initial coronavirus lockdown in 2020, U.S. broadcasters faced a dilemma. With no spectators in attendance, what do you do about the lack of crowd noise? This is the fascinating story of…

Timing: Part 6 - Synchronization

The need for synchronization rears its head in so many different endeavors that it has to be accepted as one of the great enabling technologies.