When one second changes the outcome: What Michigan-Western Michigan teaches us about broadcast timing

In live sports, timing is supposed to be simple.

The clock runs. The cameras capture the action. Replay systems record it. Production systems process it. Graphics tell the audience what’s happening.

And when the game reaches 00:00, everyone should agree it’s over.

The Michigan-Western Michigan game on September 5 offered a dramatic reminder that the reality can be considerably more complicated.

With Western Michigan appearing to have secured a major upset, Michigan’s final Hail Mary attempt initially appeared to end the game with the clock at zero. But following a replay review, officials determined that one second remained. Michigan was given another opportunity, and quarterback Bryce Underwood connected with JJ Buchanan on a 47-yard Hail Mary for a 13-12 victory.

One second changed the outcome. And that second has since become much more than a football debate.

The exact cause of the discrepancy remains unclear, and more accurate network synchronization wouldn’t necessarily have prevented the incident. But the controversy provides a useful illustration of a challenge broadcast engineers deal with every day: multiple systems can observe the same event, but they need a trusted reference for when that event occurred.

The Mid-American Conference has now formally appealed to the NCAA and College Football Playoff, arguing that the replay process used an incorrect timing feed. The NCAA has clarified its timing procedures following the incident, although it does not have a mechanism to overturn the game’s result.

For broadcasters and media technology professionals, the broader question isn’t who was right in this case. It’s how production environments can ensure that cameras, replay systems, graphics engines and other technologies share a common understanding of time.

The broadcast timing challenge

The controversy centered on a deceptively simple question: Was there one second left?

According to the Big Ten, its replay process used synchronized cameras, including a camera focused on the stadium clock. The conference stated that the cameras used for replay were synchronized before kickoff and that the replay review showed one second remaining when the Western Michigan defender made contact with the ball.

The challenge was that the broadcast audience saw something different.

NBC’s televised replay showed its game-clock graphic reaching zero as the play unfolded, while the replay process used by officials determined that one second remained. NBC subsequently clarified that its broadcast cameras are not the official timekeeping source. That distinction is important.

The issue wasn’t simply whether one clock was “right” and another was “wrong.” The deeper issue was that different systems presented different timing references for the same event. And that’s precisely the type of challenge modern broadcast infrastructure is designed to address.

As broadcasters migrate from traditional SDI architectures toward IP-based production, timing becomes distributed across the network. Production systems across the IP network depend on accurate synchronization to operate together.

In an IP environment, timing becomes part of the network infrastructure.

Why PTP matters in modern broadcast

Precision Time Protocol (PTP), defined by IEEE 1588 and adapted for professional media through standards such as SMPTE ST 2059, provides a mechanism for distributing a common, precise timing reference across an IP network.

Rather than treating each device as an independent source of time, PTP allows networked equipment to synchronize to a common timing source. That matters for applications such as:

• Live sports production
• Remote and distributed production
• SMPTE ST 2110 IP media networks
• Production studios and broadcast centers
• Mobile production trucks
• Event venues and stadiums
• Audio/video synchronization 
• Replay and contribution workflows
• Distributed media processing

Oscilloquartz PTP grandmaster solutions are designed to provide and distribute precise timing across IP broadcast networks, supporting professional media timing requirements and SMPTE broadcast profiles.

This provides a foundation for synchronizing networked production systems while also allowing broadcast organizations to integrate timing into complex IP architectures.

From a single clock to a trusted timing architecture

A PTP grandmaster provides the timing reference for the PTP network, distributing precise time to other connected systems. In a broadcast environment, that reference can be distributed throughout the production network to help maintain alignment between cameras, servers, replay systems, audio equipment, production systems and other networked devices. This is particularly important as production environments become more distributed.

A live event may involve:

Each stage introduces additional systems and timing dependencies. A resilient architecture therefore needs precision as well as continuity and confidence in the source of time.

Resilience matters when GNSS is part of the architecture

GNSS has traditionally been an important source of timing for broadcast and other critical infrastructure. But GNSS signals can be vulnerable to interference, obstruction, jamming and spoofing.

For broadcasters, that creates another architectural question: What happens to the network’s timing reference if GNSS becomes unavailable?

Oscilloquartz timing solutions can incorporate multiple timing sources and backup mechanisms to improve resilience.

For example, the edgeSync+™ Series OSA 5422 combines PTP grandmaster and NTP server capabilities with GNSS, optional Iridium PNT (previously Iridium STL) advanced holdover capabilities and protection against jamming and spoofing. The platform can also support White Rabbit as a software-enabled enhancement for applications requiring extremely precise synchronization.

For environments where GNSS reception is difficult or an indoor timing source is preferred, the accessSync™ Series OSA 5405-S provides a compact PTP grandmaster and NTP server with integrated Iridium PNT and GNSS capabilities.

This approach shifts the conversation from simply asking, “What is the time?” to asking, “How confident are we in the time, and what happens if our primary timing source disappears?”

The bigger lesson for live production

In a live production environment, timing discrepancies can manifest in very different ways, from audio/video alignment issues and frame synchronization problems to replay discrepancies, production errors or uncertainty when reviewing an event after the fact.

As more broadcast workflows become IP-based and distributed, synchronization becomes an important part of the architecture.

A resilient timing architecture can combine:

• PTP grandmasters to provide a precise network timing reference
• Redundant timing sources to improve availability
• GNSS and complementary timing sources such as Iridium PNT
• Holdover capabilities to maintain timing through temporary reference loss
• Hardware timestamping for precise network synchronization
• SMPTE timing profiles to support professional media environments
• Broadcast synchronization interfaces including video sync, tri-level sync, LTC, DARS and word clock 

Together, these capabilities allow systems across the broadcast environment to operate from a common, trusted understanding of time.

Timing is part of the production infrastructure

The Michigan-Western Michigan game ended with a 47-yard Hail Mary.

But the story that followed was about one second – and whether everyone involved had the same understanding of when that second existed. For broadcasters, that’s the part worth paying attention to. Because live production rarely gets a second chance.

The objective is to make sure every system counts the same seconds.