Services Global Viewpoint – March 2023

For as long as we will need video and audio signals, we will also need waveform monitors and vectorscopes. There’s no getting away from the fact that there are many variables in the acquisition of sound and vision, as well as the signal processing, that influence the levels and have significant implications for video and audio quality. However, in the IP and IT world, measuring the video and audio essence is only part of the story.

SDI and AES formats embed the sampling clock into the essence to enable accurate synchronization of downstream equipment. In IP, we cannot take this for granted as IP is asynchronous by design leading to a whole load of new challenges such as buffer management and packet reordering, to name but a few.

Although it might sound counter intuitive, SDI does use buffer management in the guise of frame synchronizers. However, they are much more predictable as the incoming feeds have frame rates that are similar to the studio frame rates, and if they’re not, then we use standards converters.

In the IP world, packet reordering, buffering, and even packet loss are all elements of the infrastructure that are taken care of at higher protocol levels using ARQs (Automatic Repeat Request) such as TCP. The downside of using TCP is that it introduces latency into a signal flow, and more concerning, is that the latency is often highly variable. Again, this is by design to reduce the risk of congestion collapse and account for lost packets.

Using ST2110 and other UDP/IP based protocols requires packet loss and ordering to be as low as is physically possible. FEC helps rectify transient errors, but any long-term buffering or packet drop issues are a significant challenge for broadcasters. Corresponding issues may not necessarily arise in IT applications such as web page access as a response between 20ms and 250ms would go largely undetected by the user, however, the same could not be said for high quality broadcast audio and video.

As we progress on our IP journey then it is becoming increasingly clear that there will be many challenges ahead of us which have not yet manifested themselves, especially when we start to really stress asynchronous IP networks to gain increasing efficiencies. Consequently, we cannot rely on vendors to provide all the answers.

IP was born out of the need for software applications to communicate and exchange data. So, it should come as no surprise to discover that software tools hold many of the answers to solving the challenges that lie ahead of us. And this will require broadcast engineers to make their own tools, which is nothing new. But instead of filing out the end of a flat blade screwdriver to pivot plugs from the deepest recess in a production switcher or sound console, we will instead need to build software tools to record and analyze IP streams.

Wireshark, Python, and C are our greatest friends and form the foundations of many of the software tools broadcast engineers will be building over the coming years. Wireshark facilitates real-time IP stream recordings; however, we must be careful when determining the source of the PCAP timestamps. Are they derived from a high precision hardware clock on the NIC or from the highly variable software clock derived from the kernel? Python is fantastic for writing and executing scripts to analyze data quickly, and C for those wanting to perform more real-time evaluation, monitoring and fault finding.

Building software tools will become second nature to the broadcast engineer over the coming years to the point where their chosen tool will be a laptop and their screwdrivers and wire cutters will disappear into the history books.