There was a time when any self-respecting broadcast engineer had their own collection of miniature adjusters taking pride of place in their shirt pocket. With dignity they would carry their own bespoke toolkit, the product of many years of learning, to deal with the intricacies of maintaining and repairing servo-controlled tape machines.
IP infrastructures, by their very nature encourage software processing and distribution of media signals throughout a broadcast facility. It’s almost unheard of for an engineer to jump into any part of the IP system and adjust a capacitor, resistor, or inductor. So, does this mean the age of oiling the signal flow wheels is now over? Don’t you believe it! We’ve only just begun! A new and interesting path in our continued quest for engineering enlightenment awaits.
The early days of SDI are a precursor to what is now happening in broadcasting. It either worked, or it didn’t. Analog PAL and NTSC gave us some warning when things weren’t good but in the early days of SDI, the screen just went blank. Tools to monitor and decode the signals were in their infancy and esoteric cable testing equipment came with options such as “pathological signal test”. Very useful if you knew what this meant.
But that was all fixed relatively quickly by the test and measurement manufacturers who have been doing a sterling job ever since, especially as we explore faster and faster bit rates to 12G-SDI and beyond.
With IP, we can build on vendor test and measurement equipment to further our understanding of IT systems and networks. We can even build our own diagnosis and workflow systems by learning some rudimentary programming skills.
General IT tools such as Wireshark allow us to record and analyse IP streams. But Wireshark doesn’t look at the intrinsic elements of video and audio. However, it does give us a recorded IP stream to analyse and play with.
With some basic programming skills, we can open the recorded stream and find out what’s going on. Furthermore, our knowledge of broadcasting empowers us to identify IP patterns and decode video and audio.
I accept I’m making this sound a lot easier than it really is, but the analogy I would use is to think about how you learned valve technology or solid-state electronics. You achieved this by building a device and measuring using oscilloscopes, voltmeters and ammeters. You rolled up your sleeves and got your hands dirty.
The same is true of programming and in a similar way to learning transistors and cameras, not only do you learn what is going on under the hood of the IP stream, you also learn how the infrastructure works, to a deep level. Just as you did with valves, transistors, and integrated circuits.
Although vendors are doing a fantastic job of building a new breed of tools and devices to measure IP video and audio streams, especially when analysing timing, market forces mean they will never be able to build you a specialist widget that only you need.
Writing code to analyse video and audio transport streams is a life-long journey. Every line of code you write allows you to learn something new about programming, the IP infrastructure, and more importantly, how a real-time video and audio IP system works. Computer programming is the software screwdriver of the IP world.