Audio/Video Synchronization
Audio/video synchronization aligns sound and picture on a common playback timeline while accounting for their different delays.
A clap is easy to use as a synchronization check: the hands meet at a visible instant, and the matching sound has an identifiable attack. If those events are separated, first observe whether the gap stays constant or grows.
Synchronization aligns presentations on a common timeline, then accounts for different processing and output delays.
Convert each stream's time units
Video frames and audio sample blocks need not arrive together or represent equal durations. Their timestamps say when the reconstructed results belong in the presentation.
For an illustrative timebase conversion:
| Stream timestamp | Unit duration | Presentation time |
|---|---|---|
| Audio: 960,000 | 1/48,000 second | 20 seconds |
| Video: 500 | 1/25 second | 20 seconds |
The numbers differ by nearly three orders of magnitude but designate the same instant. Comparing raw timestamp integers without their units would be meaningless.
The decoder also needs its input early enough to produce the output for that instant. Decode order, buffering, and presentation scheduling are related but distinct jobs.
Schedule around different output delays
Suppose a picture path takes 100 ms from submission to display, while a sound path takes 20 ms to the audible output. To present both at a chosen wall-clock instant of 20.000 seconds:
- Submit the picture at 19.900 seconds.
- Submit the audio at 19.980 seconds.
Submitting both at 19.900 would make the sound arrive at 19.920, 80 ms before the picture. Adding 80 ms of audio delay could compensate for that fixed difference.
These are hypothetical processing delays, not universal television or player values. They show why equal submission/packet-arrival time is not synchronization.
Separate fixed offset from clock drift
A fixed offset can come from unequal processing paths, an initial timestamp difference, or an uncompensated encoder/filter delay. Delaying the earlier presentation can address that particular constant gap.
A rate mismatch accumulates instead. A hypothetical audio device consuming 48,002.4 frames per wall-clock second instead of 48,000 runs 50 parts per million fast. Over one hour it consumes 2.4 × 3,600 = 8,640 additional frames, representing 0.18 seconds at the intended rate.
Changing the starting delay does not remove the rate difference. A player can need clock tracking, scheduling changes, or appropriate rate conversion to keep the presentations aligned over time.
Preserve the timeline through a seek or conversion
A seek jumps the desired media time, but decoder buffers can still contain data from the previous position. The player must flush/reinitialize appropriate state and establish the new audio/video relationship.
A transcoded track also has its encoder delay and final padding. Timestamps and trimming must account for them rather than making them extra audible programme time.
These mechanisms explain why a file can start aligned and change after a seek, or why one delivery/output route differs from another.
What the timing symptoms reveal
| Observation | First useful comparison |
|---|---|
| Same offset at beginning and end | Compare fixed delays and starting presentation times |
| Increasing mismatch | Compare timebase interpretation, rates, and clocks |
| Sudden change after seeking | Compare seek/reset behavior |
| Only one audio output affected | Compare that output path's buffering and processing |
| Same misplaced event on several paths | Examine the source's timing/presentation |
For an Emby session, record the event, approximate gap, and whether it changes with time. A comparison through another client or output route then isolates a boundary. This is more useful than choosing an offset value before knowing whether the problem is an offset at all.