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...

Designing IP Broadcast Systems: Integrating Cloud Infrastructure

Connecting on-prem broadcast infrastructures to the public cloud leads to a hybrid system which requires reliable secure high value media exchange and delivery.

Designing IP Broadcast Systems: Where Broadcast Meets IT

Broadcast and IT engineers have historically approached their professions from two different places, but as technology is more reliable, they are moving closer.

Comms In Hybrid SDI - IP - Cloud Systems - Part 2

We continue our examination of the demands placed on hybrid, distributed comms systems and the practical requirements for connectivity, transport and functionality.

KVM & Multiviewer Systems At NAB 2024

We take a look at what to expect in the world of KVM & Multiviewer systems at the 2024 NAB Show. Expect plenty of innovation in KVM over IP and systems that facilitate remote production, distributed teams and cloud integration.

NAB Show 2024 BEIT Sessions Part 2: New Broadcast Technologies

The most tightly focused and fresh technical information for TV engineers at the NAB Show will be analyzed, discussed, and explained during the four days of BEIT sessions. It’s the best opportunity on Earth to learn from and question i…