Will The Transition To IP Disrupt Live Production Workflows? Part 1

It's hard to attend a broadcast industry trade show or read industry news without seeing much discussion about the enormous technological changes in the works that will impact the broadcast industry over the next few years, writes Paul Robinson, CTO, Tektronix Video Product Line.

Some changes such as 4K/UHDTV, High Dynamic Range and High Frame Rate video could be regarded as evolutionary, but the transition to an all IP video workflow is regarded by many as a revolutionary and disruptive technology change that will demand entirely new skillsets and infrastructure.

The migration to IP will impact everyone across the broadcast chain to varying degrees, including content producers, broadcasters, content providers, content distributors and equipment manufacturers. However, possibly the biggest impact will be to live production workflows.

The Application of Standards
In general, when we refer to video over IP in the context of any video production workflow, we are referring to the distribution of either baseband or lightly compressed video over Real Time Protocol, commonly referred to as 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 relatively straight forward.

Although there are a number of specific industry standard and proprietary methods for the distribution of video over IP, the majority of early deployments in Europe have adopted the use of SMPTE ST 2022-6, and in some cases, have made provision for the use of SMPTE ST 2022-5, which defines a method for Forward Error Correction (FEC) and also SMPTE ST 2022-7, which defines a method for seamless protection switching of two SMPTE ST 2022 datagrams, in order to provide failover protection.

The asynchronous nature of IP has the advantage that many different traffic types can be carried across a network without having to be concerned with synchronisation, but this presents a challenge in the production environment where synchronisation is critical to enable frame-accurate switching as well as synchronous video processing. To provide the necessary "genlock", there remains the need for a timing standard, which for both IP and Ethernet networks is provided in the form of the IEEE 1588 Precision Time Protocol, commonly referred to as PTP. This is the basis of a recently introduced PTP standard, specifically intended for the timing and synchronisation of video over RTP networks – the two part SMPTE ST 2059-1 and 2059-2. The first part of this standard refers to "the generation and alignment of interface signals to the SMPTE Epoch" and the second part refers to the definition of a "SMPTE profile for use of IEEE 1588 Precision Time Protocol in professional broadcast applications".

Keeping PTP Simple
The adoption of video over IP along with the use of PTP infers that any such network requires a network time server, in order to provide the PTP genlock functionality equivalent to that delivered by a Sync Pulse Generator (SPG) in SDI networks.

This PTP network time server is generally referred to as 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 and a Slave is a device that synchronises to a Master. A Grandmaster is a Master that is synchronized to a time reference source. In the context of broadcast applications, PTP Grandmasters are usually synchronized to GPS, GLONASS or both, in order to derive accurate time-code relative to the 1970 Epoch. It should be noted that PTP Grandmasters always use the 1970 Epoch and if deployed in a hybrid SDI/IP network, it is possible that the SDI signals may be referenced to the SMPTE 1958 Epoch. The Tektronix SPG8000A hybrid PTP Grandmaster and SDI SPG is able to phase its baseband timing outputs relative to either the 1970 or 1958 Epoch dates.

As defined, PTP is a method for distributing time over a network, with a single Grandmaster providing the source of time, to be synchronised by one or more Slaves. The Grandmaster periodically transmits sync messages, which the slaves use to derive the time. 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. Unfortunately the delay in 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. The Slave is now able to calculate the difference between its own clock and that of the Grandmaster using the master-to-slave packet delay (sync packet-delay) and slave-to-master delay (delay request packet-delay). Even if the network delay in both directions is different, the Slave is able to adjust its clock to ensure alignment by averaging the delay across both paths.

This article is continued in Part 2 here.