Can PTP Solve The IP Time Space Continuum And Sunset Drop Frame?

PTP - Precision Time Protocol is the new “BLACK”. PTP is a more accurate version of NTP – Network Time Protocol, which controls the synchronizing and timing of data packets in the IP environment. In the world of bits and bytes, locking each bit to a slice of time must be highly accurate.

I know an engineer who is implementing an IP solution at his facility and continuing to get grief about it. One of his challenges is explaining PTP - Precision Time Protocol to broadcast system designers and engineers.

Time is a critical element in broadcast and production. However there are different kinds of time. There is time of day reference, you know that cesium atomic clock located somewhere secret in the Himalayas, or GPS time (satellites or deep space), which of course references back to the same cesium. This is the reference that we use for our master clocks; for system timing and synchronization. Then, of course, there is (SMPTE) Timecode which is a highly accurate frame time reference to track, cue and align recorded materials that broadcast and production depend on.

First we need to de-couple System Timing and Synchronization from timecode. They are two different discussions. Both important, but different.

Timecode is an accurate counter of elapsed time (it can be associated to time of day but still tracks elapsed time), This was developed to solve the problem of a frame accurate reference for videotape for tracking, cueing and editing. Timecode really has nothing to do with time.

A look back at time

First timecode. Before timecode there was Pilot Tone. The pilot tone system was devised in the days when film sound was recorded on a battery-powered tape recorder, such as a Nagra. Because audio tape has no sprocket holes (like film) sync was maintained by recording the pilot frequency, which was generated by the film camera. The tone represented a precise representation of the camera's running speed. The synchronization came from a pulse cable connected from the film camera to the audio recorder. A camera with a sync motor sends a 60/50 Hz signal to the recorder, which is recorded as a sine wave pilot tone. When video appeared the 60/50Hz synchronizing reference continued. Can you say NTSC/PAL?

Drop frame timecode dates back to a compromise that was invented to accommodate color NTSC video. The NTSC designers wanted to retain compatibility with existing monochrome televisions.


System Timing or Synchronization is different. Analog television used an interlaced format to reduce flicker in the displayed image to transmit each frame of video. This meant that the odd lines and even lines were transmitted separately. Because each frame consists of two fields, the video signal needs to be transmitted at 60 fields per second. To assure that the fields arrived in time and in sync, pulses were created to lock the fields together.

Each field started with a series of vertical sync pulses and each line of video included a horizontal sync pulse separating one line from the next. The television visual spectrum was considered grayscale so the sync pulse was placed in the non-visual space that was beyond the black range. The sync pulses are said to be blacker than black. Back at the broadcast center all the equipment had to be integrated so that synchronization would be move between sources, like production switching, without visual disturbances.

Back to the Future

And then the world went digital. While SDI represented the conversion from analog to digital, with regard to master timing and synchronization, genlock or blackburst remained. New sync pulses including Tri Level and word clock appeared. Timecode stayed the same only now is embedded in the SDI stream and even though we are longer interlaced, the frame rate remained at 29.97 not 30fps and there is still drop frame timecode.

NLE or computer based editing doesn’t really need timecode for frame accuracy the same way it doesn’t need vertical or horizontal sync. Computers rely on internal clock pulses for reference while computing and moving data. In a network there is a master clock reference that provides time of day to all network devices. With all these clocks there should be no challenge synchronizing multiple bit streams - right?

And now we are moving from one form of digital (SDI) to another – IP.  With that we have another time conundrum. Computers and network switches don’t know what to do with genlock. It does not compute. (Sorry- I had to.) Timecode is just another packet of data.

Accurate time across a network is important for many reasons as even small fractions of a second difference can cause problems. For example, distributed procedures depend on coordinated times to ensure that proper sequences are followed. Network security depends accurate and synchronous time across the network. Scheduled processes and application services depend on synchronized clock times.

Timing in an IP world

Once again IP is a disruptive technology. Even sync is changing. How do we splice an MPEG stream accurately and stay in sync? We don’t switch or transition between streams, we need more words so we splice. Fortunately there are standards.

Computer networks are no different that SDI systems when it comes to latency across devices and latency created by the number of devices or routes the signal travels.

What is NTP and PTP?

Network Time Protocol (NTP) is the networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. NTP uses Coordinated Universal Time (UTC) – that is accessed thru the internet to synchronize computer clock times within a millisecond and theoretically, sometimes to a fraction of a millisecond.

Precision Time Protocol (PTP), IEEE -1588, was created to address the need for greater accuracy than NTP provided. PTP is accurate in the sub-microsecond range, supporting media transport, measurement and control systems. Where NTP uses UTC, PTP or IEEE15888 uses International Atomic Time, which is even more accurate.

Standards

The current standard for NTP is Internet Engineering Task Force (IETF) [2010] RFC 5905, and actually a new request for comments is due soon. There are NTP servers that connect to one of the many clock services and NTP is introduced to the network at the router or Layer 3 switch level (see decoding terminology).

The broadcast industry has been using NTP as a clock source and companion to GPS. However, it is fed into the master sync generator which provides sync reference to everything else. If everything is connected to the network and all transport is on the network, we then have to introduce a new sync and timing reference. Enter PTP and SMPTE 2059 Parts 1 & 2.

  • SMPTE ST 2059-1 Generation and Alignment of Interface Signals to the SMPTE Epoch.
  • SMPTE ST 2059-2 SMPTE Profile for Use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications.

So what does any of this really mean? SMPTE Part 1 was created to enable the alignment of SDI timed signals to native IP signals using PTP. SMPTE Part 2 is the actual IP based timing reference for all media using the IEEE1588 PTP reference model.

The transition to IP is more than encoding and decoding audio and video. The information consists of more than just figuring out where to put all that stuff that used to fill the vertical blanking interval, (VBI). It is the entire integrated infrastructure, synchronizing devices and signals and new methods to align systems and devices. Timing sources into the production switch is one of many processes that change when everything moves to IP.

Understanding the way networks can and do synchronize is another critical area that needs discussion and education. Finally, can someone explain why we still need Drop Frame?

Gary Olson is author of the book,

Gary Olson is author of the book, "Planning And Designing The IP Broadcast Facility". It is available from major book sellers.

You might also like...

HDR & WCG For Broadcast: Part 3 - Achieving Simultaneous HDR-SDR Workflows

Welcome to Part 3 of ‘HDR & WCG For Broadcast’ - a major 10 article exploration of the science and practical applications of all aspects of High Dynamic Range and Wide Color Gamut for broadcast production. Part 3 discusses the creative challenges of HDR…

IP Security For Broadcasters: Part 4 - MACsec Explained

IPsec and VPN provide much improved security over untrusted networks such as the internet. However, security may need to improve within a local area network, and to achieve this we have MACsec in our arsenal of security solutions.

Standards: Part 23 - Media Types Vs MIME Types

Media Types describe the container and content format when delivering media over a network. Historically they were described as MIME Types.

Building Software Defined Infrastructure: Part 1 - System Topologies

Welcome to Part 1 of Building Software Defined Infrastructure - a new multi-part content collection from Tony Orme. This series is for broadcast engineering & IT teams seeking to deepen their technical understanding of the microservices based IT technologies that are…

IP Security For Broadcasters: Part 3 - IPsec Explained

One of the great advantages of the internet is that it relies on open standards that promote routing of IP packets between multiple networks. But this provides many challenges when considering security. The good news is that we have solutions…