What's In The SDI Signal?
There are some variations of SDI, Here, we are going to stick to the 4:2:2 component, standard definition 525 line, 30 frame-per-second version.
It would be nice to think that we could ignore the SDI all together, if it's just a way of transporting video, but to understand the stuff on an SDI waveform monitor, we need to look at some of the dirty bits. In NTSC video, nanoseconds (billionths of a second) were important to us. In SDI, we have to use PICOseconds (trillionths of a second). Yeesh! Fortunately, even though the signal has tight and fast internal timing, out old video timing is much more relaxed, because automatic time correction is included in most digital units.
Up until now, we have talked about 8-bit bytes a lot. Component SDI systems use 10-bit words ("byte" infers 8-bits, "word" can be any defined length. 10 bits translates to 1024 ( two to the power of ten) analog levels. Interchanging 8 and 10-bit information is easy in the digital domain... eight bit systems simply ignore the two least significant bits (the one's place and the two's place), and 10-bit systems slap a couple of zeros onto the 8-bit bytes (in the least significant digit spots). Think in 10-bit from here on.
But don't think that the video has 1024 levels! SDI reserves some of the lower and some of the higher numbers for special functions. Black is at hex 040, and 100% white is at hex 3AC. 10-bit words have to use three-digit hex numbers. It is best just to use the hexadecimal numbers, but if you have to have it in decimal, black is at decimal 64 on the scale of 1024, and white is at 940 out of 1024 (The Microsoft Windows calculator converts all of these numbers if you switch its view to "scientific").
So, what's in the component SDI signal? Mostly serial bits that represent the picture at 30 frames per second, Y, Pr, and Pb sampled at ten-bit accuracy.
There is something that's not in the SDI signal... Sync. The space left in the NTSC signal for horizontal sync is almost 11 microseconds, out of a total of 63.5 for one whole scan line, so the horizontal blanking interval with the sync pulse occupies about 17% of the line! Leaving twenty-one lines in each field for the vertical blanking interval leaves another 8 percent of the time free, although astute readers will notice that if we're going to count those 42 (2 fields x 21 lines) whole lines, we can't also use them in our 17% figure above. Let's guess that there is about 20% of the time spent in NTSC, carrying sync pulses and blanking the display while it retraces.
In SDI, all that is needed is a signal that indicates the start of a sync period, and the receiving equipment can fill in the blanks by itself. SDI reserves special numeric sequences to mark the start-of-active-video (SAV) and end-of-active-video (EAV). SDI is a regular alphabet-soup of TLA's (three-letter-acronyms), but most of them are memorable. SAV and EAV have sub-codes following that indicate whether the picture scan is at the right side of the display and/or at the bottom of the display. SAV and EAV use some of the "reserved" numbers in the range of 0-1024 that aren't used for video.
SDI spits out bits at the rate of 270 MILLION per second, so with about 20% of the time no longer used for sync pulses and blanking, we have somewhere around 54 million bits-per-second sitting around doing nothing. Let's put 'em to work...
"Room for other stuff" (ROS) would have be a good name for it, but sadly, it's called "Ancillary Data", which somehow suggests that it's secondary or somehow not as important. In fact, there is a lot of important stuff in the ancillary data of the SDI. By the way, the horizontal sync area data is officially HANC (Horizontal Ancillary), and the vertical sync area is VANC (I don't have to spell it out, do I?) They are pronounced "Hank" and "Vank".
The most significant thing in the ancillary data is audio. There is room for several channels of AES audio in the ancillary data. While the video flows continuously, and in time, the audio travels in chopped-up packets in the old sync-time areas, and is reassembled in a buffer at the receiving end. There are so many bits flying through the cable at great speed, that this "chop and buffer" can still deliver several high-quality channels of audio in perfect lip-sync.
When audio is included in the SDI stream, it is known as Embedded Audio. Embedded audio has many benefits...
... and of course, has some downsides:
The average TV installation will have areas of non-embedded audio (Like the studio) where audio is carried, switched, and patched on AES cables (that look like video cables and patches) and processed by separate units (like the audio console), and areas of embedded audio (like Master Control), where feeds simply need to be switched along with their audio.
SDI is really a different world. It's really no more complex that the old analog world, it's just different. You can imagine that designing an SDI installation might be a nightmare, especially with lots of analog equipment still needing to be incorporated. Technology to the rescue! Digital electronic components get smaller, cheaper and more powerful every minute. Glance at the following unit that is only one rack unit high:
This thing is a frame syncronizer that will take analog or digital video in and deliver analog or digital signals out. As a bonus, it will embed or de-embed audio! It also does about 50 other things that might need doing, and is typical of the new breed of really useful devices that we will have to work with. Unfortunately, as our gizmos get smaller and do more things, they get more menus... a lot more menus!
The SDI signal has some interesting ways of testing itself continuously. To go into this accurately and in-depth would create an eye-glazing monster-document, so we will cover the concepts, and accuracy be darned...
The SDI stream is a huge and fast string of zeros and ones. If a bit is detected incorrectly, it might or might not have a serious effect. Missing a least significant bit in the video might not show at all, missing a most significant bit in the video will cause one pixel to be half of it's brightness (or twice the brightness!). Missing a bit in the SAV sequence might, well, we don't want to know!
10110010 = 4 01010111 = 5 11111111 = 8
Computers have long used error-detection methods, and they are a science in themselves. The cyclical redundancy check or CRC is as old as digital data. In 8-bit byte land, what happens to the number 255, when you add one to it? Did everybody get an answer of ZERO? Just as the trip-odometer in a car rolls from "999" to "000", binary bytes roll from 255 to 0. To create an error-checking "fingerprint", we can count all of the ones in a sequence using an 8-bit byte, and we will have a number (called a "checksum") between zero and 255 that is unique to the sequence. We append our checksum to the data, then at the receiving end, we do the same calculation, and compare the result. If the checksums match, it is very likely that we have not miss-read any bits (or we have miss-read exactly 256 bits!). We can also do this with bigger bytes (words) and fancier math to increase our accuracy.
SDI uses a CRC that is based on counting up one whole video field of bits. So. Now we know that we had an error, but we don't really know anything else. When an error occurs, and note is placed in the stream, and then it gets interesting...
SDI calculates CRC's for the entire field, for the active picture area by itself, and for the Ancillary data.
One or more of the five flags at the left can be inserted in the video stream to indicate the error status in the stream. Using this information, the device in the chain that is causing trouble can be tracked down without having to take anything out of service, or having to "patch around" the various units.
Not all devices have internal error-checking.
Be aware that changing the picture in any way (like adding a superimposed graphic) will cause an "error" to be detected.