In the old days, when broadcast systems were analog, or SDI serial digital, we needed to synchronize video signals so we could switch cleanly between sources, insert graphics and so on. We did it with a leader clock and some SPGs, with the same reference time cascaded through the production center.

Now we are moving to IP connectivity, and – with SMPTE ST 2110 – to architectures that treat audio, video and metadata as separate objects. These objects are then routed using IP networks, through COTS ethernet switches, which inherently do not care about synchronization.

But we still need synchronization. We need the start of picture of each video source to be perfectly aligned so we can seamlessly switch. We need microphones to be in phase so we can mix them together. We need broadcast standards of deterministic timing to be imposed upon IP connectivity.

The IT industry, for all sorts of non-broadcast reasons, created its own synchronization standard, called Precision Time Protocol or PTP, which is standardized as IEEE 1588. To be precise, we use version two of the standard, from 2008.

The PTP standard was designed to be flexible, recognizing that different applications would have different requirements from a reference time structure. SMPTE, therefore, was able to adopt IEEE 1588-2008 and set on it constraints that are specific to the requirements of media architectures. This broadcast profile is known as SMPTE ST 2059-2.

The fundamental architecture of SMPTE ST 2059 is a grandmaster clock, which probably gets precise time of day from a service like GPS or GLONASS. The grandmaster feeds a number of boundary clock switches – you could think of these as the follower SPGs. The boundary clock switch acts as a follower to the grandmaster, and as a leader to the edge devices.

Setting  the time on a follower clock is similar to you trying to set your watch to the time signal on a radio broadcast. The announcer might say, “At the tone, it will be 11:00 a.m.,”, then the tone would precisely define the time. PTP synchronization does the same thing, but with the tone coming first via a Sync message, then a Follow-up message saying, “At that tone, the time was 11:00 a.m.,” enabling you to calculate the time.

A difference between traditional timing and IP is that, while in SDI, the propagation delay of timecode is constant, in an IP network, there are latencies through each switch and device. And those latencies will vary randomly, because of delays through the switch (which will be dependent on traffic) and the time taken to process signals.

To calculate those latencies, a leader clock will send a Sync message then a Follow-up message. The follower then sends a Delay Request, to which the leader responds with a Delay Response. From these four messages, it is possible to calculate the latency through that part of the communication path – including delays in processing, as well as in the network – and set the follower time to the same time as the leader.

As we will see in a later blog, SMPTE’s constraints on IEEE 1588-2008 deliver synchronization across the network to within a few µs, with a lock- up time less than 10 seconds, which is impressive.

The good news is that this is all achievable. At the “JT-NM Tested” event before the NAB Show in 2019, around 40 manufacturers took part, each demonstrating compliance with SMPTE ST 2059-2, and thereby showing that multi-vendor IP systems can be synchronized.

I’ll talk about good design practice to achieve reliable SMPTE ST 2059 performance in my next blog.