Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


An introduction: IP and Precision Time Protocol

Why would we want to move to using IP when SDI has served us so well for decades? The most commonly quoted reasoning is the ability to use Commercially Off-The-Shelf (COTS)

Why would we want to move to using IP when SDI has served us so well for decades? The most commonly quoted reasoning is the ability to use Commercially Off-The-Shelf (COTS) IT-based infrastructure, which takes advantage of the economies of scale of the IT industry when compared with the relatively small broadcast industry. In addition, it offers reduced cabling cost and weight.

Probably the biggest advantages, however, are the much greater routing flexibility offered and the enablement of new workflows such as downstream/centralised production. These new workflows in turn are likely to lead to new types of content to provide to viewers and with it new sources of revenue.

The application of standards

When we refer to video over IP in the context of video production, we are referring to the distribution of either baseband or lightly compressed video over Real Time Protocol (RTP). The advantage of using RTP as opposed to Universal Datagram Protocol (UDP) for the transport layer is twofold. RTP packets are time-stamped making the measurement of packet delay variation easier, but critically the packets also carry a sequence number, making the detection of dropped or out-of-order packets straightforward.

There are a number of specific industry standards and proprietary methods for the distribution of video over RTP. SMPTE ST 2022-6 is a standard designed to transport uncompressed SDI video, embedded audio and metadata over RTP. Although it is possible to send audio on a separate flow, by for example using AES67, the payload is always an entire SDI datagram.

A second method for transporting video over IP networks is defined by the Video Services Forum as VSF TR-03. This separates video, audio and metadata elements into separate IP flows. Advantages claimed for this method are inherent avoidance of audio embedding or wasted bandwidth associated with carrying SDI over IP. A related standard, TR-04 defines how SMPTE ST 2022-6 media flows can be used in an interoperable manner within the context of a TR-03 environment.

Another option is the Evertz ASPEN format (submitted to SMPTE as RDD 37), which has some similarity to TR-03 in that separate IP flows are dedicated to carrying video, audio and metadata elements, but in the case of ASPEN, these elements are carried on an MPEG-2 Transport Stream (TS) over RTP. Similar advantages are claimed for ASPEN when compared to SMPTE ST 2022-6.

Keeping PTP simple

When carrying video over IP in a live production environment, it is critical to consider synchronisation and timing. To provide the necessary genlock equivalent to black burst in an SDI network, there remains the need for a precise timing standard, which is provided in the form of the IEEE 1588-2008 Precision Time Protocol (PTP version 2). This is the basis of SMPTE PTP standard, specifically intended for the timing and synchronisation of video transmitted over RTP networks – SMPTE ST 2059.

The ultimate source of clock synchronisation is a PTP Grandmaster, with a device that derives its timing synchronisation from PTP being referred to as a PTP slave. A master is a device that provides the time in a given PTP domain and a slave is a device that synchronises to a master.

Within any PTP domain, there are a number of message types used to establish time within that network. Announce messages are used to establish the synchronisation hierarchy and provide the clock status and clock criteria used to determine which clock becomes the Grandmaster. Sync and follow-up messages are transmitted by the Grandmaster and are used by slaves to derive the time.

Delay request messages are a request for timing information and are sent from the slave to the Grandmaster in order to determine the reverse path propagation delay between the slave and the Grandmaster. A delay response message is sent by the grandmaster and contains the time of receipt of the delay request message by the Grandmaster. The slave is now able to calculate the offset between its own clock and that of the Grandmaster as well as the oneway delay between itself and the Grandmaster.

Accuracy and reliability is key – The BMCA

One reason for PTP’s suitability to broadcast applications is the resilience provided by the use of the Best Master Clock Algorithm (BMCA). This allows the most accurate master to automatically take over the duties of Grandmaster when the previous Grandmaster loses its GPS lock, gets disconnected from the network, or is unable to act as Grandmaster for any reason.

The BMC algorithm runs on all clocks in a network and uses a number of criteria to determine which master should be Grandmaster including the following in priority order:

– User definable priority one field (the lowest value <= 128 wins)
– Clock class (eg GPS vs free running)
– Clock accuracy
– Clock variance (jitter and wander)
– User definable priority two field (the lowest value <= 128 wins)
– Clock source port ID (usually the ethernet MAC address)

PTP clock types

Ordinary clocks are those devices that are at either end of a network and are not switches or routers. A slave-only clock never acts as a master, whereas a master/slave clock can act as either and a Preferred Grandmaster is configured to never become a slave.

It is vital that switches and routers in any IP video network that relies upon PTP for synchronisation are PTP aware. That is, they are 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 a 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.


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 IT professionals generally have little experience of the challenges associated with live production workflows. The companies best placed to provide equipment and support during the transition are those who have experience both of the challenges of the live production environment, as well as extensive experience of the challenges associated with the distribution of video over IP networks.

Paul Robinson, CTO, Tektronix Video Product Line