In projects I’m involved with and classes I instruct, whenever the possibility of using HD-SDI comes up, I jump at it. It is such an elegant way to pass HD video and audio. It is simple. It is easy to be redundant for mission critical systems. It’s just a one-way stream with no need for handshaking and negotiations and ugly DRM. Plus, the “toys” that accept HD-SDI signals are incredible, and sometime even come with joysticks. JOYSTICKS, PEOPLE! But most importantly, it always works. Or it did…until recently.
The biggest problem we, as AV folk, run into is lack of standards between manufacturers. Device commands, video timings, audio bandwidth (the list goes on and on) are examples of specifications where different manufacturers think their take on it is superior to their competitors. Manufacturers see differentiators. Integrators and designers see headaches.
It is very difficult to get different manufacturers to play nicely with one another. This is the reason for documented EDID Plans, 3rd Party Control Systems, 3rd Party Converters, etc. I’ve worked with systems where video conferencing codecs required four video converters to be able to pass video to and from the system, and then, of course, an audio delay to adjust for proper lip sync, all because the codec passed video differently than the system matrix switcher. However, this lack of standards is also the reason we get paid the big bucks, am I right, guys?
Conversely, in the broadcast world, they have standards for their standards! It used to be that if a device had a 3G HD-SDI output, you could rest assured that it would work with a 3G HD-SDI input of a device from a different manufacturer. It was a beautiful thing.
And then the waters started getting a little muddy. Broadcast manufacturers needed to support a ton of different video formats, and also realized that AV clients wanted their town hall meetings to be broadcast quality. So systems started mixing broadcast and AV equipment. With all these new video timings, limitations on how the video was supported and recognized were exposed. And that’s why my HD-SDI stopped working.
We had a matrix switcher from a well-known manufacturer interfacing with a production switcher from a different well-known manufacturer. Both were capable of passing 3G HD-SDI. It should have been a no brainer. However, video from the matrix switcher would not show up on the production switcher. If a source was connected directly to the production switcher, there was no problem. As soon as the same source was routed through the matrix switcher…no video. On the flip side, when we sent the same source through the matrix switcher to displays, it worked fine. In other words, everything was working a little bit. Sources worked directly with the production switcher. The matrix switcher passed those same sources to the displays with no problem. It was only when the matrix switcher routed those sources to the production switcher we had the problem.
I was at a loss. I’ve never seen anything like this before. We were dealing purely in the broadcast realm, with great equipment, with my beloved HD-SDI, and it wasn’t working. It would have been so much better if it just didn’t work at all. That it was kind of working made it that much more infuriating. We had test equipment, but they couldn’t tell us much about what was going wrong. Could HDMI be easier to troubleshoot than…*gulp*…HD-SDI? I shuddered even thinking that. My heart was broken.
Well, after hours, on the phone with tech support from both companies, and sending both devices to one manufacturer, it turns out that some packets were not being inserted into the video signal from the matrix switcher, and the production switcher required those packets to function. That was why there was no video. In the “golden days” of 3G HD-SDI (you know…like last year), it used to be easy to figure out the video format by determining the number of lines and samples between horizontal and vertical transitions in the video stream. However, now that we need to deal with dual link interfaces and segmented-frame standards, this method of determining video format no longer works. C’mon in SMPTE 352M! (Didn’t I tell you? Standards for their standards!)
SMPTE 352M is the VPID (Video Payload Identifier) standard which allows a unique way to determine the video format. The matrix switcher was not inserting SMPTE 352M packets in their outputs, and they were not passing the VPID from the sources to the destinations. Those packets were not required by the displays (so video showed), but they were required by the production switcher (so video didn’t show). The result? Say it with me…firmware upgrade. Now all is well.
I’m used to this firmware upgrade game with AV people. I guess I have to get used to it now with broadcast people as well. Our industry can get pretty creative, and I understand that there is no way manufacturers can test all the perturbations our whacky AV minds come up with. But, that was my baby. That was my beautiful HD-SDI. And now she’s just another video protocol to me.