Audio and video out of sync: lip-sync problems that grow over time
Lip-sync drift is one of the few faults every viewer can detect instantly. It has two families of cause - the stream and the player - and telling them apart is the first step.
Two families of cause
If the offset is constant from the first frame and the same on every device, the stream is wrong. If it starts correct and drifts, or appears after a seek, a pause or an ad, the player or the device pipeline is wrong. Checking the same asset in a desktop player with a known-good clock is the fastest way to decide which side to investigate.
Source and encoder problems
Audio and video reach the encoder through different paths and can carry different timestamps from the start, especially in live production where an audio embedder or a separate audio feed adds its own delay. Transcoding and transmuxing can then damage what was correct: presentation and decode timestamps written inconsistently, decode time exceeding presentation time, or timestamps that fail to increase monotonically across a segment boundary. Ad stitching introduces gaps at the join when the ad and the content were not timestamped against the same timeline.
- Audio and video tracks offset at the source, common in live contribution.
- Incorrect PTS/DTS relationships after transcoding or repackaging.
- Timestamp gaps or overlaps at ad-break and stitching boundaries.
- Audio and video segments of different durations that drift apart over a long asset.
Player and device problems
On the device, the usual cause is a buffer underrun on one track only: video stalls for a moment while audio keeps going, and the pipeline resumes without pulling them back together. Seeking, pausing and resuming and fast-forward all exercise the same re-synchronisation path, and on some television pipelines that path is unreliable, so the offset appears after the viewer does something rather than during steady playback.
Hardware adds its own offsets. Audio passed through to a sound bar or AV receiver arrives later than audio decoded in the set, and the television's picture processing delays video by a variable amount depending on the picture mode. Neither is the app's fault, but both land in the app's support queue.
Monitor, correct and fix upstream
The player should compare the audio and video presentation timestamps at the playhead continuously and log the offset; drift that exceeds a few tens of milliseconds is then a measurable event rather than an anecdote. Small drift can be corrected in place with a dropped frame or a brief audio stretch, and every seek, pause, resume and ad transition should end with an explicit re-sync of both tracks rather than trusting the pipeline.
Upstream, the muxer must write consistent timestamps for both tracks against a shared reference clock, and the transcoding pipeline should validate PTS/DTS relationships on output. Testing lip-sync on a real television with a sound bar attached catches the device-level cases that a desktop browser will never show.