Audio that is out of sync in an FFmpeg YouTube stream needs a diagnosis before it needs a new flag. Compare the offset near the beginning with the offset later: a mismatch that stays about the same suggests a start-time alignment issue, while one that grows points towards timing or clock behaviour that needs closer inspection.
There is no universal FFmpeg command that fixes both patterns. The useful change depends on your command, input sources, clocks and measured offsets, so keep the original command and change one relevant setting at a time.
Measure sync near the start and later
First establish what the stream is doing rather than relying on a single impression. Choose a recognisable event with both a visible action and a sound, such as a person clapping, a bell strike or a spoken word with a clear mouth movement. Compare its audio and video timing shortly after the stream begins, then repeat at a few later points. If you can, use a local recording or test stream so that YouTube playback buffering does not become part of your measurement.
Write down the apparent offset and whether the audio leads or follows the picture. For example, note that a bell is roughly half a second late early in the stream, then check whether it is still roughly that late several minutes later. The value in that example is illustrative, not a recommended setting or a diagnosis. Use the actual events and timings from your own stream.
Be consistent about the point you are measuring. A player may buffer audio and video differently, and a live player can change its delay as it catches up. Compare the same player and playback conditions where possible; if the problem is present in a local recording too, that helps separate the encoder's timing from a viewer's playback path. You can also inspect the source file and FFmpeg's timing information, but neither replaces checking what the audience actually hears and sees.
Keep a short log: time from stream start, event observed, audio lead or lag, and estimated offset. You do not need laboratory equipment to classify a clear pattern, but avoid false precision. If you cannot decide whether the difference is increasing, gather more observations before adjusting the command. A timing change made from one point can improve that point while making the rest of a long broadcast worse.
If the stream is intended to run overnight, do not treat a brief opening check as proof that sync will hold. A useful companion is this guide to checking a prerecorded YouTube stream without keeping a PC on, which covers confirming that the broadcast is reaching YouTube. For sync work, though, you still need recordings or observations from both the start and later playback.
Distinguish a fixed offset from growing drift
A fixed offset means the audio is early or late by approximately the same amount at each observation. That pattern makes the relative starting positions of the streams a sensible place to investigate. It does not prove the streams started at different times: source timestamps, a processing stage, or playback can also contribute. The finding narrows the next questions; it does not identify the cause by itself.
Growing drift means the mismatch changes as the stream continues. Audio may start close to sync and then steadily lead or trail the picture. This points towards a timing relationship that is not holding over time, such as separate clocks or source timestamps that do not represent real elapsed time consistently. Again, this is a diagnostic direction, not proof of any particular fault.
A third pattern is worth keeping distinct: an abrupt jump. If sync is stable, then suddenly changes after a source reconnect, file boundary or timestamp discontinuity, a gradual compensation setting may hide the symptom without fixing the event that caused it. Mark when the jump occurs and inspect logs and timestamps around that point.
| What you observe | First avenue to investigate | What not to assume |
|---|---|---|
| Similar offset near the start and later | Input start-time alignment and any processing that offsets one stream | That an offset option is automatically the right fix |
| Offset steadily increases or decreases | Source timestamps, sample timing and whether independent inputs share a clock | That changing the initial offset will stop ongoing drift |
| Sync is stable, then jumps | Discontinuities, reconnects, file transitions or timestamp warnings | That a larger buffer or queue repairs relative timing |
| Different results in different players | Playback buffering and test conditions as well as the stream itself | That the encoder is necessarily at fault |
This distinction prevents a common wasted effort: shifting the entire output when the mismatch is accumulating. A uniform shift moves audio and video together, so it preserves their relative timing difference rather than correcting it. FFmpeg's format and muxer documentation describes timestamp handling; use it alongside the command documentation for the options in your build.
Check source timestamps and clocks
Next identify where the audio and video come from. If both are streams in one media file, their timing may already be related through that file's timestamps. If audio comes from a microphone or audio interface while video comes from a capture device, or if audio and video are read from separate live sources, they may have independent timing. That distinction matters more than whether the command looks complicated.
Record the FFmpeg version and build, then inspect the input stream information and logs. Look for audio and video start times, time bases, sample rate, nominal frame rate, missing or irregular timestamps, and warnings about timestamp discontinuities. The exact tools and output depend on your FFmpeg build and inputs; the goal is to learn what timestamps FFmpeg receives, not to collect fields without using them. The project's documentation page links to command and component references, and the FFmpeg command-line documentation explains its input and timestamp options.
Ask whether audio and video timestamps come from a common clock. FFmpeg's -isync option aligns a target input using the start-time difference from a reference input. Its documented expected behaviour assumes the inputs' timestamps derive from the same clock source. If two devices run on separate clocks, applying -isync without checking that condition is not a dependable cure for drift; it can align an initial relationship without making the clocks stay aligned.
If the source is a file, inspect whether its timestamps are continuous and whether the audio and video streams start together. If it is live capture, note which device supplies each stream and whether either reconnects or reports timing warnings. For a looped file, check what happens at the loop boundary. A problem that begins at every repeat has a different shape from a small mismatch that accumulates continuously.
Preserve the full command and relevant log excerpt, but remove the private YouTube stream key before sharing them. Avoid copying just the final output options: input-specific options can depend on their position relative to each -i, and the source configuration may be the decisive evidence. If you also have an RTMP connection problem, treat that separately from sync; this FFmpeg YouTube no-audio troubleshooting guide addresses a different symptom and should not be used to infer a timing cause.
Review sample rate and stream start timing
A sample rate describes how many audio samples represent a second of sound. It is one useful part of the evidence, but seeing a familiar rate in the output does not prove that the input's timestamps or clock match the video clock. Check the audio stream's reported rate, the input's timing, and any resampling already present in the filter chain. Avoid changing sample rate merely because the stream is out of sync; a format conversion is not automatically a timing correction.
For a fixed offset, test an input-specific start-time adjustment only after deciding which input should move and in which direction. FFmpeg's -itsoffset adds an offset to timestamps for an input; a positive value delays that input. Its placement and effect depend on the command's input structure, so consult the documentation for your installed version and test with a copy of the command. Do not guess a value from a single imprecise observation and assume it applies to the whole broadcast.
-isync is another possible start-alignment tool where its shared-clock condition fits the source setup. These tools address relationships at the start; neither should be presented as a general solution to an offset that keeps growing. When inputs are separate devices, first determine whether their clocks are actually related and whether the offsets remain stable.
For accumulating mismatch, FFmpeg's audio resampler supports timestamp-based compensation, including stretching, squeezing, filling or trimming samples. Its async option is disabled by default; async=1 enables filling and trimming, while larger values set the maximum sample compensation per second. The resampler also documents first_pts for padding or trimming at the start, and min_comp as a threshold for compensation. These are mechanisms to investigate, not values to paste in blindly. Check the documentation for the installed build, examine the source timing and test whether any compensation improves later sync without damaging the audio.
An initial padding or trimming option can address a start difference, while ongoing compensation responds to timestamp differences. Confusing those jobs can create a result that seems right at the opening but drifts later, or one that hides a source timing fault. Make a note of the measured offset before and after each test and keep the actual option values with the command version that produced them.
Inspect the FFmpeg command and output
Read the command from left to right and mark each input, its audio and video stream selection, filters, output mapping and output options. Confirm that the intended audio and video are actually being mapped. A stream-selection mistake can look like a sync fault if, for instance, you are listening to a different audio track than the one you inspected. Keep a safe copy with the stream key redacted, and do not post a live key in a forum or log excerpt.
Pay attention to timestamp options applied per input versus those applied to the output. Shifting all output timestamps uniformly does not repair a relative audio/video mismatch: both timelines move together. Likewise, packet interleaving or buffering settings concern how output packets are handled; do not treat a larger queue as a general drift correction unless you have evidence that a specific buffering failure is occurring.
Video frame handling is relevant because a change there can alter the relationship you are trying to measure. FFmpeg documents -fps_mode passthrough as forwarding frame timestamps and cfr as duplicating or dropping frames to reach a requested constant frame rate. The documentation also notes that a muxer can further modify timestamps. Changing frame mode or requesting an arbitrary rate may affect video timing, so it is not automatically an audio-drift fix. Establish what the input timestamps look like before testing a video timing change.
Use the option reference for the FFmpeg version you run. Online documentation is regenerated and can describe a newer revision than an older installed build. The FFmpeg resampler reference covers the compensation options, but verify availability and behaviour against your build rather than assuming the newest online page exactly matches it.
Do not change several unrelated flags in one edit. Keep one known-good command, make a single evidence-led change, and record the result. If you alter an offset, frame mode, resampling and buffering together, an improvement or regression will not tell you which change mattered. Save the output logs and compare the same test events under similar playback conditions.
Test any change across the full stream
A setting that fixes the opening can still fail later. Test from near the beginning through a meaningful later section, including a loop boundary or source reconnect if either is part of normal operation. For a continuous channel, verify that the stream remains coherent over the period that matters to your viewers, not just during a short preview.
Use a private or otherwise appropriate test broadcast before changing a channel that viewers rely on. YouTube's current guidance for live streaming and encoder setup should be checked before publishing changes; see YouTube Help on live streaming. This is also where you should confirm current channel and stream setup requirements. No encoder timing adjustment guarantees a particular platform outcome.
Compare measurements from the same points you used for the baseline. Note if the audio lead or lag remains stable, shrinks, grows more slowly, or develops a new jump. Listen for artefacts as well: aggressive sample compensation can affect perceived audio quality, and a timing improvement is not useful if it introduces audible gaps or distortion. If results vary between tests, check whether the source clocks, input start times or player conditions also varied.
If no single FFmpeg change produces repeatable results, return to the source evidence rather than stacking more timing options. Test each input on its own where practical, inspect timestamp warnings, and simplify the filter graph temporarily to isolate which stage changes the timing. Keep your notes, the exact command, logs and the tested duration together so that a later edit can be compared with the same baseline.
If the issue is not the timing itself but keeping a long-running broadcast online while your computer is unavailable, that is a separate operating question. StreamNeo can remove the need to leave your own computer running for an uploaded-video broadcast, but it does not diagnose or correct an FFmpeg timing problem in an existing live-input command. For a local setup, this guide to keeping a YouTube music stream running with a PC in India can help you think through the power and continuity side without confusing it with sync troubleshooting.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Will adding -itsoffset fix audio that drifts over time?
Not by itself in the general case. It changes timestamps for an input and can be tested for a measured start-time difference, but an offset that grows suggests you should investigate timestamps and clocks over time. Measure both before and after the change.
Should I add aresample=async to every FFmpeg stream?
No. Timestamp-based audio compensation can be useful when the source timing evidence supports it, but the appropriate settings depend on the input and the measured behaviour. Check your installed FFmpeg documentation and test the result across the stream rather than adopting a guessed value.
Can changing -fps_mode correct an audio sync problem?
It changes how video frame timestamps are handled, so it may alter video timing, but it is not a generic audio-drift remedy. First inspect the video timestamps and determine whether they are implicated. Avoid arbitrary frame-rate changes as a substitute for diagnosing the audio and video clocks.
Why does sync look different on YouTube than in my local test?
Playback buffering and viewing conditions can affect what you observe, so compare like with like and check both a local recording and the live playback where possible. If the local output is stable but viewers see a changing mismatch, investigate the playback path as well as the encoder. Keep the observation times and conditions in your notes.