Genlock in a networked world

Five-minute facts about packet timing

Once upon a time there was an industry that needed data sharing and time synchronization among devices that were spatially disbursed. So, the industry developed standards for data transfer and timing signals that each device could interface to, and everything worked. But the technical professionals in the industry did not live happily ever after. A network for data and an additional network for timing signal had to be installed and maintained. Also, both the data and timing networks used expensive niche technology, which was understood only by technical professionals who already had experience in that specific industry. Then came Ethernet and the Internet Protocol and everything changed.

This is in fact the story of every industry that uses networks, that is every industry that requires spatially dispersed devices to cooperate.  For this post I will talk about the broadcast industry, sometimes now referred to as broadcast and media, since so much content is now streamed rather than broadcast.  Traditional devices used in live television such as news and sports, or in television and movie/video production used a technology called black burst, or sometimes black and burst to provide timing alignment for video, and word clock for audio. Tighter requirements for higher fidelity signals required improved standards, tri-level sync for video, and Digital Audio Reference Signal (DARS) for audio. Locking devices to these various timing signals is referred to as Genlock. Figure 1 shows the black burst and DARS waveforms, which are often aligned in time with each other to assure video and audio signals are properly aligned. Timestamps inserted directly into the video recording for later processing could be supported by linear timecode.    

Packet networking technologies, Ethernet and the Internet Protocol (IP), first took over the office building network. Because of its flexibility it could be adapted to a wide variety of use cases.  This flexibility was key to replacing single purpose networks in specialized applications like power grid substation automation, industrial automation, telecommunications networks, and many other specialized applications including broadcast.  As each industry adopted Ethernet (and later WiFi) and IP, the economies of scale made the network hardware less expensive.  If and engineer or technician moved from power distribution to broadcast they already know about Ethernet and IP. Furthermore, these packet networks can support time transfer using the NTP and PTP protocols. The data and timing networks are the same network! SMPTE and the Audio Engineering Society have created profiles of PTP specifically for broadcast applications.  The profiles are AES67, and SMPTE ST2059-2. SMPTE and AES even had the good sense to make sure that their profiles can work together.  As a result, there is wide consensus that the broadcast industry will move to packet networking technologies. Broadcast operation is not supposed to go down or have outages, and the move to packet technologies doesn’t change that.  So Ethernet/IP based broadcast studios will have redundant networks as shown in Figure 2.   

This is clearly better, so everyone in broadcast has switched to packet networks, right? Well … not everyone, and most deployment that have changed are mixed old and new. The sticking point is that broadcast equipment can be quite expensive, tv/movie quality cameras cost on the order of $100,000 US dollars. Add to that adding support for Ethernet and PTP takes time. Add to that the inertia of professionals working with what they know. This is especially true for adding PTP, which is more of a niche technology than Ethernet or IP. The net result is that the broadcast industry is somewhere in the middle of the transition from legacy broadcast technology to packet based technologies. Even when a broadcast studio does get connected to Ethernet the last transition is often moving the timing to PTP. So many deployments need a mixed legacy/packet timing system. Figure 3 shows three ways to do this:
1. Legacy timing signals can be supported from a time server that is providing PTP (and usually NTP also)
2. Legacy timing signals can be built directly into broadcast equipment
3. An adapter node in the network can translate PTP to legacy timing signals

If you have any questions about packet timing, don’t hesitate to send me an email at doug.arnold@meinberg-usa.com, or visit our website at www.meinbergglobal.com.