Click on the Image to Enlarge
We are at the beginning of a long-term transition to IT-based infrastructure and those involved in the production and facility side of video have little experience with the new technology, but conversely are extremely experienced using SDI and all the issues associated with its use. This, coupled with a huge investment in existing technology, makes it likely that a hybrid SDI/IP infrastructure will be in place for some years.
As such, production facilities will require equipment that can operate seamlessly and reliably in a hybrid environment. And because a broadcast live production network is entirely reliant on a stable reference and any timing and synchronization devices “must work.”
In general, when referring to video over IP in the context of any video production workflow, the focus is on the distribution of either baseband or lightly compressed video over Real Time Protocol or RTP. In a live production environment, it is critical to consider synchronization and timing. The asynchronous nature of IP allows many different traffic types without synchronization concerns, but this presents a challenge in a production environment where synchronization is critical for frame-accurate switching and synchronous video processing.
ACHIEVING GENLOCK
The necessary “genlock” for both IP and Ethernet networks is achieved using IEEE 1588-2008, or PTP (Precision Time Protocol) v2. This is also the basis of a recently introduced SMPTE PTP standard, specifically intended for the timing and synchronization of video transmitted over RTP networks. Although PTP provides a mechanism to synchronize the real time clocks of devices on an Ethernet-based network, it does not make the network itself synchronous.
Deriving the correct time in a PTP network.
The adoption of video over IP and the use of PTP means a network time server is required to provide PTP genlock functionality equivalent to that delivered by a sync pulse generator (SPG) in SDI networks.
Any grouping of synchronized clocks is referred to as a PTP domain. The PTP network time server is called a PTP grandmaster, with a device that derives its timing synchronization from PTP referred to as a PTP slave. A master provides the time in a given PTP domain and a slave is a device that synchronizes to a master. A grandmaster is the ultimate source of clock synchronization.
For broadcast applications, PTP grandmasters are usually synchronized to GPS, GLONASS or both, in order to derive accurate timecode using the 1970 Epoch. To enable legacy equipment support, hybrid PTP grandmaster and SDI SPG equipment is now available on that market that can phase baseband timing outputs relative to either the 1970 or 1958 Epoch dates.
OVERCOMING NETWORK DELAY
As defined, PTP is a method for distributing time over a network, with a single grandmaster providing the source of time, to synchronize one or more slaves. In an ideal world the network delay could be programmed into each slave which could then be offset to the time in the received packet to derive the correct time. Such symmetry can only be relied upon in point-to-point IP links. Unfortunately, the delay in switched/routed IP networks is both variable and asymmetric, so the slave devices must periodically send delay request messages to the grandmaster. The grandmaster accurately time stamps these messages on receipt and the time of receipt is sent back to the slave in a delay response message.
As shown in Fig. 1, the slave is now able to calculate the difference between its own clock and that of the grandmaster using the master-to-slave sync packet delay (T2-T1) and slave-to-master delay request packet-delay (T4-T3). The offset (slave time – master time) = [(T2-T1)-(T4-T3)]/2 and the one way delay = [(T2-T1)+(T4-T3)]/2. For the slave time to be now correct, the propagation delay in both directions must be equal.
If the propagation delay in both directions is in fact different, then the slave is offset to “correct” for this by adjusting its clock to a value of half the asymmetry. The clock’s control loop adjusts the slave time to make the master-to-slave and slave-to-master propagation delays appear to be equal. That is, the control loop adjusts the slave time such that T2-T1 = T4-T3.
PTP CLOCK TYPES
It is vital that switches and routers in any IP video network that relies upon PTP for synchronization are “PTP aware” and able to account for their own queuing delay to ensure downstream timing accuracy. This can be achieved in one of two ways. The first is by the switch acting as a transparent clock which hardware time stamps sync and delay request messages on arrival and departure and adds the difference to a correction field in the message.
The second way for a switch or router to account for its own queuing delay is to act as a boundary clock, which receives time from a master on one slave port and provides one or more master (not grandmaster) ports to downstream slaves in a PTP domain and in doing so, removes the effect of its own queue.
PLANNING AHEAD
For hybrid IP/SDI broadcast applications, it is essential that the PTP grandmaster provides support for application specific video and audio PTP profiles, such as SMPTE 2059 and AES67, as well traditional SPG features including black burst, tri-level and SDI out. All the above protocols must be referenced to the same GPS clock, or such a hybrid IP/SDI network would be inoperable.
Paul Robinson is a 29-year veteran of the test and measurement industry. In his current role, Paul is CTO for Tektronix’ Video Test Business focused on developing test, measurement and monitoring solutions aimed at the enabling the deployment of digital television and helping to bring IP video products and services to market.
Paul joined Tektronix in 1986 as an Applications Engineer and has held a wide variety of senior roles within the company both in Europe and the U.S. Paul started his professional career in the broadcast industry and prior to joining Tektronix, he worked for the BBC as a senior systems engineer. Paul has a B.Sc. in Applied Physics and a DUniv from Buckinghamshire New University.
