Solving SMPTE ST 2110 Synchronisation Challenges with TimeBeat

Why broadcast moved to PTP

For decades, broadcast facilities synchronised their video and audio equipment using analogue reference signals — black-and-burst for video, word clock for audio, AES11 for digital audio reference. These signals were distributed over coaxial cable in a parallel reference network that ran alongside the main video signal path. The reference network was conceptually simple, electrically robust, and operationally well-understood. It also imposed serious limits on the topology of the facility: every device that needed sync had to be physically wired to the reference, and every reference change rippled through dedicated cabling.

When the broadcast industry moved to IP-based production with SMPTE ST 2110 — separating video, audio and ancillary data into individual essences carried over standard IP networks — the analogue reference network couldn't follow. The replacement, defined by SMPTE ST 2059-2, is a PTP profile that uses IEEE 1588 to deliver the same frame-accurate synchronisation across the IP fabric that black-and-burst used to deliver across coax. Every device that participates in an ST 2110 production — cameras, vision mixers, multiviewers, gateways, recorders, audio embedders, graphics generators — synchronises its local clock via PTP and uses the resulting time reference to align its essence streams with the rest of the facility.

What SMPTE ST 2059-2 actually specifies

SMPTE ST 2059-2 is the broadcast-industry PTP profile, defined by SMPTE specifically for the synchronisation needs of professional video and audio production. Like other PTP profiles (G.8275.1 for telecom, 802.1AS for TSN), it constrains the more general IEEE 1588v2 standard to a specific set of defaults that broadcast equipment from any vendor will interoperate around.

The key differences from telecom profiles are: message rate (8 sync messages per second for ST 2059-2, versus 16 for G.8275.1), transport (multicast over IP rather than multicast over Ethernet layer 2), domain number (typically 127 in broadcast deployments), end-to-end delay mechanism (rather than peer-to-peer), and BMCA configuration tuned for stable single-grandmaster operation rather than the fast failover behaviour that telecom needs. The differences are technical but consequential — a grandmaster shipping with G.8275.1 defaults and dropped into an ST 2110 facility will not interoperate cleanly until its profile is changed.

ST 2059-2 also defines a specific approach to phase-aligning video frames to absolute UTC, so that a 25-frame-per-second PAL stream and a 29.97-frame-per-second NTSC stream can both be aligned to the same timing reference. The phase-alignment rules are profile-specific and one of the more subtle parts of an ST 2110 commissioning exercise.

Where ST 2110 sync deployments actually fail

After supporting a decade of broadcast IP transitions, we can list the failure modes from memory. None of them are protocol failures. All of them are operational.

• ●Mixed PTP profiles on the same fabric. A single G.8275.1 device left over from a telecom integration breaks BMCA across the studio. Audit every device.
• ●Asymmetric fibre lengths between studios. ST 2110 deployments often span multiple racks or buildings. Asymmetric one-way delay between PTP master and slave is the dominant systematic error in any deployment longer than a few metres.
• ●Untested grandmaster failover. A single-grandmaster facility is one PSU failure from a complete loss of timing. A pair of grandmasters that has never been failed over in production is one BMCA misconfiguration from the same outcome.
• ●Mixing AES67 audio with ST 2110 video on the same PTP domain. AES67 typically uses domain 0; ST 2110 typically uses domain 127. Same fabric, different domains, different grandmasters needed unless explicitly cross-configured.
• ●Holdover oscillator under-specified for the GNSS environment. Studio buildings often have poor antenna access. An OCXO that drifts out of frame-accuracy budget within an hour of GNSS loss is a regular source of incident reports.
• ●No phase-offset monitoring. When sync degrades subtly (e.g. an extra 100 ns of asymmetry on one path), nothing breaks visibly until a multi-camera shot reveals the misalignment. By then the show is on air. Continuous phase-offset monitoring is the difference between catching it in commissioning and catching it on broadcast.

What good operations looks like

A production-grade ST 2110 timing fabric has the same operational properties as any other PTP deployment, with the broadcast-specific addition that the consequence of a sync excursion is visible on air. Concretely, a properly run facility has at least the following.

A redundant pair of grandmasters, both running ST 2059-2 with correct defaults, configured for BMCA failover, with the failover behaviour tested in maintenance windows on a defined cadence (quarterly is a sensible floor). A single grandmaster is acceptable for a development environment but not for any production studio.

Multi-band, multi-constellation GNSS at the grandmaster, with antenna placement that has been tested for sky visibility and multipath. Studio buildings frequently have antenna constraints that introduce subtle GNSS-related drift; specifying the antenna placement properly upfront is worth the effort.

Hardware boundary clocks at every aggregation point in the studio fabric, all running the ST 2059-2 profile. Network switches that aren't explicitly PTP-aware should not be on the timing path; if they have to be, they introduce variable jitter that ST 2110 cannot tolerate.

Continuous phase-offset monitoring on every essence-producing device, with alerts on excursions outside the operational tolerance. The TimeBeat Sync Insight platform was built for this; any equivalent that gives the broadcast operations team visibility of every clock in the fabric will do.

Documented commissioning tests that include forced failover, GNSS antenna disconnection, asymmetric delay measurement and end-to-end frame alignment. The first time you discover a sync bug should not be on a live broadcast.

Where TimeBeat fits

TimeBeat builds open-standard PTP grandmaster hardware that supports SMPTE ST 2059-2 with correct defaults out of the box, and the Sync Insight observability platform that broadcast operations teams use to monitor the timing fabric in production. Our hardware is OCP-aligned, our software runs on linuxptp, and our customers include broadcasters, OB truck operators and studio integrators across European and US markets.

If you're commissioning an ST 2110 facility or troubleshooting a sync issue in an existing deployment, the broadcast engineering team is happy to walk through architecture, profile configuration and observability patterns specific to your facility.