All 14 articles in this series are now available in our free eBook ‘Understanding IP Production Networks - 2026 Edition’ – download it HERE.

All articles are also available individually:

Broadcast has timing intrinsically built into the signal paths. For example, analog PAL and NTSC have field and line sync pulses to synchronize the scanning process in cathode ray tubes. Color subcarrier bursts synchronize the flywheel oscillator to lock the color demodulation frequency. And SDI and AES have bi-phase modulated clocks built into their signals so that the receiver clock can lock to the sample clock.

Clock synchronization is extremely important in both synchronous and asynchronous digital television systems. The problem we are trying to solve is to keep the encoder and decoder sample clocks at the same frequency and in phase. If we do not do this, then one clock will run faster than the other resulting in either too many or too few samples reaching the decoder.

Lost samples of data in uncompressed signals will cause an instantaneous audio splat or loss of a video pixel. In compressed systems, the effect could be much worse as forward and reverse compression can result in a prolonged error.

Broadcasters have gone to great lengths to provide primary clock referencing for both audio and video in the form of primary sync pulse generators.

Although Ethernet uses bi-phase modulation to encode its data and clock signal, the clocks are not synchronized between network interface cards (NIC’s) so we cannot use this as a form of global synchronization.

GPS has been used in the past to lock encoders and decoders; however, it’s proved impractical when the signal path moves away from line of sight of a satellite.

Precision Time Protocol IEEE-1588 (PTP) was developed by the IEEE to address the issue of network timing. PTP was designed as a standard for many different industries and as it can provide sub-microsecond accuracy, it lends itself well to broadcast television.

PTP works in a sender (main clock) and receiver topology. One server or customized device is nominated as the main sender clock, and all other devices within the subnet synchronize to it forming a network of synchronized servers.

Although the protocol can run on any router without modification, some configuration work must be done to provide the timing packets with the fastest and shortest delay path in the network. Network engineers achieve this by setting the quality of service (QoS) in the routers for specific types of packets by using a form of rate shaping that gives priority switching to the timing signals.

The time difference between the main and receiver clocks consists of two components; the clock offset and the message transmission delay. To correct the receiver clock, synchronization is achieved in two parts, offset correction, and delay correction.

Timing Clocks

The main clock should be a very accurate generator capable of providing 1GHz clock samples, either locked to GPS or deriving its clock from an oven-controlled crystal oscillator (OCXO) in a similar way to the broadcast Sync Pulse Generator (SPG). Many established manufacturers of SPG’s include PTP clock outputs on their products.

In a similar way to time representation in Unix systems, PTP uses the concept of an Epoch clock. This is an absolute time value initialized to zero, that counts the number of 1GHz clock pulses that have occurred since zero time to provide the current time, this count is converted into human readable time with software to provide year, month, day, hours, minutes, and seconds. The Epoch (or zero time) for PTP was set at midnight on the January 1st, 1970. For example, the PTP epoch count for 08:00:00 (UTC) on November 25th, 2025, is 1,764,957,600, and the time and date for epoch count 1,764,000,000 is 16:00:00 (UTC) on November 24th, 2024.

As PTP uses a 1GHz primary clock, the granularity of the receiver clock can be accurate to 1nS. The clock should be thought of as an event clock or presentation time clock rather than an absolute pixel count.

Software timing is notoriously unpredictable hence the reason manufacturers have kept to hardware solutions for time critical processing such as video playout. When PTP main senders create timing packets, and receivers receive them, the timestamp should be inserted within specially designed network interface cards at the Ethernet layer. If it was inserted by the software stack, then jitter would occur due to the unpredictable interactions of the operating system and software stacks.

When sending a video frame, some frames will arrive ahead of their display time and some behind. Buffers smooth this out and the internal presentation software will make sure the frame is constructed before the next field pulse comes along. In effect, the frame pulses are synchronized by the PTP, so the frame rate of the receiver is locked to the encoder.

The benefits of this method of synchronization go beyond video and audio playout. PTP now provides us with a predictable event clock so we can trigger events in the future instead of relying on centralized cues. If a regional opt-out of Ads was to occur in a schedule at 19:26:00hrs, the remote playout servers would be able to switch the program at 19:26:00hrs to play the regional Ads within a timeframe of 1nS. If the schedule database is correctly replicated to all the regional playout servers, we no longer have to rely on cue tones and in-vision prompts to provide opt outs.

Daisy Chaining Devices

PTP protocol allows for primary and secondary devices to be daisy chained together so a secondary device can become primary for another subnet. In this way, we can have entire LANs and WANs synchronized together to allow broadcast devices to accurately switch and mix between sources.

In traditional analog and SDI studios there tended to be just one timing plane for the video, the production switcher. If multiple production switchers were to be used, then video synchronizers would have to be employed to provide another timing reference. PTP removes this need as the timing plane is essentially the same throughout the entire network as all secondaries and primaries become synchronous.

Another critical element of synchronization is buffering. Traditional SDI and AES systems also relied on buffers, but their size, and therefore their latency, could be kept extremely small. This was largely due to the inherent transport-layer clock synchronization built into both formats. An SDI receiver locks its frequency and phase to the sender, enabling clock-accurate data transfer with only a few SDI-clock cycles of delay, and AES behaves in much the same way. IP networks, by contrast, were never designed to operate with this sort of synchronous, deterministic timing. Their packet-switched architecture demands deeper buffers throughout the system.

Buffering

In a packet-switched environment, often viewed as a form of time-division multiplexing, buffers serve a vital purpose: they prevent data loss. When multiple ingress links attempt to feed packets into a single egress path, as happens inside layer-2 switches and layer-3 routers, the probability of packet contention rises, especially as datarates increase. These collisions corrupt packets and lead to loss, so buffering at switch and router interfaces is essential to absorb bursts and avoid destruction of data.

The downside is that larger buffers introduce significant and, more importantly, unpredictable latency. Although bounded by the buffer depth, the actual delay experienced by any given packet becomes difficult to forecast. This unpredictability creates real problems for PTP, which relies on path symmetry between sender and receiver. Ideally, the forward and reverse latency should match. Once buffering enters the picture, particularly in busy or oversubscribed networks, achieving this symmetry becomes extremely challenging.

Asymmetric paths generate clock jitter, reducing timing accuracy for PTP-dependent devices such as cameras, servers, microphones, and audio consoles. These receivers can smooth some of the variation using software filters, but excessive jitter eventually leads to buffer underflow or overflow within the device, manifesting as visible and audible distortion.

To address variable latency, engineers have a few theoretical options: shrink the buffers, lower the network’s operating load, or increase link capacity. None are ideal. Reducing buffers or throttling data rates runs counter to the flexibility promised by IP infrastructure. Expanding link capacity, effectively increasing network headroom, is highly effective but inevitably raises costs due to the more capable hardware required.

Larger buffers are simply a fact of life in IP networking, and broadcast engineers must design with them in mind if the full benefits of IP-based production are to be realized.