Live Sports Video and Data Have Different Clocks


A scorecard updates, then the video shows the play that caused the change. Both services may be working as designed. They simply travelled through different capture, processing and delivery paths.
Treat sports video and data as separate timelines until you have evidence that they are synchronized. A shared event ID does not establish a shared clock.
Identify three clocks
The event clock describes what happened at the venue. The data clock describes when an update became available to the application. The playback clock describes which moment the viewer is currently watching.
The browser's current wall-clock time is not automatically the capture time of the displayed frame. Reliable synchronization requires usable timestamps or a documented mapping between media and event data.
Measure a visible gap carefully
In a hypothetical test, a score update appears at 18:00:02 and the corresponding play appears in video at 18:00:14. The observed display gap is twelve seconds.
That does not prove the video is fourteen seconds behind the venue. The example lacks an independently established event timestamp. Name the metric according to the evidence you actually have.
Choose the product behavior
Some match centres prioritize the freshest score and label video as delayed. Others offer a viewing mode intended to reduce spoilers. If a synchronization mode delays data, make that behavior clear and preserve a way to identify data freshness.
Do not apply one guessed offset to every viewer. Buffering, seeking, device behavior and network conditions can change the playback position during a session.
Test after interruptions
Pause and resume, switch quality, background the browser and reconnect after a network loss. Check whether the visible relationship between video and score remains understandable.
Also verify what happens when video is unavailable but the data remains current. The scorecard should not falsely inherit a video failure state.
Write a synchronization evidence table
- Browser receipt time: Claim it can support – When the application received data; Claim it cannot establish alone – When the venue event occurred
- Player live-edge distance: Claim it can support – Position behind the available media edge; Claim it cannot establish alone – Full venue-to-screen delay
- Trusted matched capture timestamp: Claim it can support – Delay to the corresponding displayed moment; Claim it cannot establish alone – Equal delay for every viewer
- Two visible corresponding updates: Claim it can support – Observed gap between the displays; Claim it cannot establish alone – Which supplier caused the whole gap
This table helps product teams choose honest labels. “Twelve seconds behind the score display in this session” is narrower than “twelve seconds behind live,” but it may be exactly what the test established.
Design a viewer-state test
Start a controlled session, identify a corresponding data update and video moment, then pause playback. After resuming, repeat the observation. Finally, return to the player's available live position and observe again.
The three measurements can differ even when the data feed behaves identically. That is why synchronization should consider the viewer's playback state, not only a global source offset.
If the product offers a synchronized viewing mode, define its failure behavior. When the timing relationship becomes unknown, the interface can explain that synchronization is unavailable and let the reader choose a fresh-data view. Continuing to apply an obsolete offset would create apparent precision without evidence.
Keep this feature separate from ordinary score delivery in the scope and test plan. Synchronization is additional product behavior that must be specified and validated; it is not an automatic consequence of displaying video beside a scorecard.
Ask about timing evidence
Apple's HLS resources provide the technical starting point for HLS delivery. The supplier still needs to explain which timing information its particular service exposes.
Discuss 7 Unicorn Gaming's TV API and Score API as separate contracts. Ask for a matched event sample, timestamp definitions and expected behavior after reconnection. An honest synchronization design starts by acknowledging which clock each component can actually observe.