SDI vs. IP: Packet to Packet

LOS ANGELES—This is the second installment of a contribution from Jim DeFilippis on SDI versus IP. For Part 1, see “Which Switch is Which?”

The second tale-of-the-tape issue is delay or latency. There is delay in every device and process. It comes from the fact that electrons move at a fraction of the speed of light and that it takes more power—which generates heat—with each increase in clock speed, so to lower the power and heat, devices convert serial video (data) to parallel video (serial-parallel conversions).

If one looks at the delay through an IP switch, it is due to the necessity to buffer the packets as they arrive, are processed and then sent out. Depending on the switch design, the traffic load, and the packet size, the performance required in terms of packet loss dictates the buffer sizes. Smaller packets mean less total buffer but require an increase in the processing speed of the switch. Larger packets may require less processing speed, but necessitate larger buffers due to their size.

We assume at least a buffer large enough to handle multiple packets, like three or four. The statistics of real-time video are also a challenge for an IP switch. Most IP data traffic packet arrival times are assumed to be uniformly distributed from minimum to maximum delay (Poisson). However, in live video, the packet delivery rate at each port is a constant. Worse, because many of the video signals are synchronized, the packet arrival times will bunch up and may cause collisions resulting in dropped packets. Video statistics don’t mesh well with typical IP switches designed to carry small randomly spaced packets of asynchronous data, not the firehose-like torrent of live video.

What will be the resulting delay? There is usually a minimum delay quoted for an IP switch, which is the lightly loaded case, and a maximum delay, which is the total buffer lengths. There maybe multiple buffers in a large, staged switch). Thus, the delay will be variable but bounded. The packet delay is on the order of 5-15uS. By the way, if a packet can’t get through the IP switch within the maximum buffer delay time, it will be dropped, i.e., a lost packet.

In SDI terms, this variable latency is known as ‘jitter’. The variable arrival times of the packets to an end receive device (such as a production video switcher or effects unit) will require not only re-alignment in terms of plant synchronization (because that’s still required to do a clean cross fade or insert a graphic overlay) but will also need to re-sample and re-clock the reconstituted video signal to remove the jitter. If the overall delay variation is within a fraction of a TV line time (15uS for 1080p60), typical video equipment will be able to handle this variation. If the packet delay exceeds a TV line time, it could result in effects similar to a non-synchronous switch.

SDI has jitter, but on a much smaller scale (1-5nS). SDI signals may be offset in time from the production switcher video reference, but the offset will always be consistent and stable.

There is no doubt that upgrading a SDI router to increase the port bandwidth is a forklift type of operation. The general expectation is that an SDI router will last through a typical plant lifetime of seven to 15 years. The promise of an IP switch solution is that it is future-proof from the outset; that the routers can be upgraded by software, that they have no intrinsic limitation other than the physical maximum bandwidths and port count as discussed in Part 1. If today, there are affordable IP switches available with excess capacity, then the future is covered, right?

Well, two things to consider. One is that the half-life of IP devices is somewhere around 18 months to three years. Within that half-life, it may be possible to upgrade or expand the system. After the half-life period, there are new better models, usually at a lower cost/higher performance point. So if the future use is not within the half-life of the IP switch design, it may be better to right size the IP switch and wait for the next development cycle. Or just install a conventional SDI router.

The other point to take into account is that the only way an IP switch can compete with an SDI router, port for port, is to overdesign the switch and the switch fabric. (I’ll leave IP switch topologies for a future discussion.) When the future requirement comes up, say UHDTV, it may push the overdesigned IP switch to its limit, and may not meet the original performance specs for delay, jitter and packet loss.

Another future-proof concept that has been proposed is to use mild, low-latency video compression. A 4:1 reduction of bandwidth means a current 1080p60 plant can handle a UHDTV signal. However this adds the cost and complexity of encoding/decoding at all points in the signal flow, including monitoring points. This might be a stop-gap solution. In the history of serial digital and live production, mezzanine compression for signal distribution has not taken hold in the long run.

Having laid out a few of the issues, it should give us pause to consider carefully these two alternatives. How soon will a video production facility have to implement live video requiring more than 3Gps? What advantages and disadvantages will an all IP switch fabric represent? Will the IP vendor support the product including upgrades and for how long?

We know SDI routers work and do the job it was designed for. IP switches do what they do very well for what they were designed to do. It’ll be some time and effort until we know how IP switches perform in the fast paced world of live TV.

When the director calls for camera 3, will there be a signal for the TD to punch it up on line?

We’ll see.

One last thought. A chief technology officer from a well-known broadcast equipment vendor said in a presentation the other day that, “We have to make IP work because that’s what they are teaching to future engineers in schools today.” So we best be prepared for IP eventually.

P.S. As I wrote this article, I wondered, ‘What is the IP equivalent of a SDI Distribution Amplifier?” Thoughts? — jd

Jim DeFilippis
CEO of TMS Consulting, Inc.

im DeFilippis is CEO of TMS Consulting, Inc. in Los Angeles, and former EVP Digital Television Technologies and Standards for FOX.