If audio and animation begin together but separate during a 24/7 stream, first find out whether the offset is constant, grows with playback, or jumps at a file boundary. Those patterns point to different checks; the title alone does not identify a proven cause or a universal FFmpeg fix.
Measure the stream before editing the command. Record the FFmpeg version, inputs, output protocol and observed offset at the beginning, later in playback, and around a transition so you can test one change at a time.
Describe the sync problem precisely
Audio that seems out of step can mean several different things. A voice may consistently arrive before a character’s mouth moves; it may begin aligned and slowly lag; or it may jump after the animated story switches to another clip. Those are distinct observations, even if a viewer describes all of them as “audio drifting out of sync”.
Write down what you hear and see, not an assumed explanation. Note whether a recognisable sound belongs with an on-screen event, when you first notice a mismatch, whether it gets worse, and whether a switch between scenes or files changes it suddenly. If the stream has speech, a repeated spoken phrase or a visible action with a clear sound can help you compare moments. Do not rely only on a vague impression after leaving the channel running overnight.
Also identify where you are observing the problem. A local playback of the encoded output and the downstream YouTube player are not the same test. If a local recording appears aligned but one receiving player does not, the evidence does not yet point to the encoder alone. Keep the viewing device, browser or application, and approximate playback point in your notes; compare another player if you can.
An always-on schedule makes time and boundaries important, but it does not establish that FFmpeg has a special 24/7 defect. A story made from one long file can behave differently from a feed assembled from repeated clips. The next steps are intended to distinguish those cases before you change timestamps, filters, or codecs.
Separate a fixed offset from gradual drift
Check alignment at more than one point. A fixed offset is already present near the beginning and remains roughly the same later. Gradual drift starts close to aligned and becomes more noticeable as playback continues. A third pattern is a sudden jump: alignment is acceptable within one segment, then changes around a transition.
The distinction matters because a one-time shift and a continuing timing correction do different jobs. If the streams begin at different times, adjusting their relative start timing may be relevant. But shifting the audio once cannot, by itself, correct an offset that keeps accumulating. Conversely, a resampling or timestamp correction is not a sensible first response to a stable offset without evidence that timing is changing.
Use repeatable checkpoints rather than relying on memory. At the start, note an event and whether its sound is early or late. Check again after a representative interval, then at a later point. If the offset is approximately steady, record that. If it changes, note the direction and whether it changes smoothly or in a jump. There is no universal threshold in this guide: the useful result is the pattern in your own output.
FFplay can help you observe this. The FFmpeg Project’s ffplay documentation describes its statistics display as showing, among other items, audio/video synchronisation drift. Its documentation also explains that a master clock controls audio-video synchronisation and describes clock selection as a debugging concern. Use the display as a measurement aid, not as a diagnosis by itself: it reports playback behaviour, while you still need to identify which input, filter, timestamp choice, or receiver may be involved.
A fixed offset invites checks of stream start times and any deliberate input offset. Gradual drift invites checks of clock and sample cadence, timestamps, and how audio is handled through the filter chain. A jump near a switch invites inspection of the media and timestamps on either side of that boundary. These are investigation paths, not conclusions about your command.
Check inside a file and at transitions
First ask whether you can reproduce the mismatch within one uninterrupted asset. If a single story file starts aligned and becomes increasingly misaligned before the next clip begins, the transition is not necessary to explain the observed drift. If it stays aligned through a clip and jumps when the next one starts, concentrate on what changes at that boundary instead.
For a playlist or looping story, inspect several transitions, not only the first one you notice. Compare the end of the outgoing asset with the beginning of the incoming one. Look for a jump in the measured offset, a pause or repeated frame, or a change in audio continuity. A boundary can expose different timestamp origins or a discontinuity, but the presence of a loop does not prove that looping caused the problem.
Make the comparison as controlled as your workflow allows. Keep the same output and playback path, then test one asset by itself if you can do so without changing unrelated settings. If the issue appears only in the assembled feed, compare its inputs and transition behaviour against that single-asset result. If you cannot isolate a single file without disrupting the channel, capture a representative section and use that copy for diagnosis.
Keep a simple event log. For each checkpoint, note the asset or segment, approximate position, whether sound is early or late, and whether the offset is stable, changing, or newly jumped. This can expose a pattern such as “the same file drifts internally” or “the offset changes after each loop” without pretending that either pattern is already established.
For a playlist-based channel, keeping a YouTube playlist stream from freezing between videos is a related operational concern, but a freeze and an audio-sync jump are not the same symptom. Likewise, looping several videos with FFmpeg for YouTube Live can help you think through how your feed is assembled; do not copy a loop command into a running channel as a sync remedy without checking its assumptions.
Inspect inputs, timestamps and output settings
Before testing a correction, inventory the actual pipeline. Record the installed FFmpeg version and build, exact command, input file formats, whether the source is one file or a sequence, output format or protocol, mapped audio and video streams, and relevant filters and encoding options. Preserve the full command privately, including any options that set or preserve timestamps. A shortened command often hides the very choice that matters.
Use ffprobe to inspect the input streams’ reported start times, durations and frame-rate fields. Compare audio and video within the same asset, then compare the corresponding details across segments if the stream is assembled from several files. These fields are clues, not a verdict. Reported frame-rate values do not by themselves establish that the source is variable-frame-rate, nor do different start times alone prove an audible problem.
Pay particular attention to options and features that affect timing. Note whether the command uses -copyts, -itsoffset, -stream_loop, or -re, how streams are mapped, and whether the audio is copied or passed through a filter and re-encoded. Do not remove or add one just because its name seems related. First ask what it currently does in this particular input/output path and whether the symptom matches that role.
The FFmpeg Project’s filter documentation is the primary reference for filter options such as aresample; check the documentation for the installed build before using an option. A commonly discussed gradual-drift hypothesis involves asynchronous audio resampling, but an example setting is not a verified fix for an unspecified stream. Resampling changes audio processing, so it is not equivalent to adjusting a timestamp while leaving the audio stream copied.
Timestamp discontinuity behaviour also depends on the format and flags. FFmpeg documents automatic discontinuity correction for formats that accept timestamp discontinuities, including MPEG-TS and HLS; it also documents that -copyts disables that correction except for timestamp wrapping detection. Check the FFmpeg documentation and the relevant protocol or format details for your build and output. Do not assume that a setting intended for one format applies to another.
A global shift that makes timestamps start at zero is not the same as repairing relative audio-video timing. FFmpeg’s documentation notes that when a common timestamp shift is applied, relative differences between audio, video and subtitles are preserved. Therefore, “start from zero” is not sufficient evidence that a misaligned pair will become aligned.
Choose a test that matches the pattern
Use the diagnosis to select a question to test, not a command to paste in blindly. The comparison below describes the purpose and trade-off of each investigation path; it does not promise that any one will repair your stream.
| Observed pattern | First question to investigate | Type of change that might eventually be relevant | Important limitation |
|---|---|---|---|
| Offset is present early and stays steady | Do the audio and video start times differ, or is an input offset already applied? | A relative start-time adjustment | It shifts timing once; it does not correct accumulating drift. |
| Offset grows during one asset | Are clocks, sample cadence or timestamps diverging during uninterrupted playback? | A version-appropriate audio timing or resampling approach | Audio may need to be decoded and re-encoded; verify filter semantics first. |
| Offset changes at a loop or segment boundary | Do the incoming timestamps reset or jump, and does the format support discontinuity correction? | A correction suited to the input format and timestamp handling | The boundary is a clue, not proof that looping is the cause. |
| Local output and a receiving player disagree | Does the mismatch appear in the same captured output when played elsewhere? | A receiver or playback-path investigation | Do not change the encoder until the observation is repeatable. |
For gradual drift, the community FFmpeg cookbook offers an aresample example, but treat that as a hypothesis to verify against current official documentation and your installed build, not as a tested prescription for your stream. Avoid recommending the legacy-looking -async spelling as a generic fix: check what your version supports and distinguish a command-line option from an audio filter. If a test requires audio re-encoding, account for that change in your output configuration and compare sound quality as well as sync.
For an apparent discontinuity, identify the input format and timestamp flags before changing discontinuity handling. The format matters, and so does whether timestamp preservation has been requested. An indiscriminate flag change could alter timing in a way that masks one symptom while changing another. If the issue is a constant offset, do not use a continuing correction solely because the word “sync” appears in its name.
Keep operational hosting separate from sync remediation. Running an FFmpeg process on a different machine can help with a computer that cannot stay on, but a VPS or other host will not correct wrong timestamps in the input or command. For the broader question of where a persistent feed runs, see running an FFmpeg YouTube stream from a VPS; treat it as an operations decision, not an audio fix.
Test one change at a time
Make a copy of the command or configuration before editing it, and keep a known baseline. Change only one relevant setting for each test. If you alter input offsets, timestamp preservation, audio filtering, codec settings and output protocol together, an improved result will not tell you which change mattered. A regression will be just as difficult to untangle.
Use a representative test that includes enough uninterrupted playback to reveal the pattern you are investigating and, where relevant, the same transition that triggered the problem. Do not decide that a gradual issue is fixed because the first few minutes sound right. Compare at the same checkpoints used for the baseline: start, later playback, and boundary where applicable. No fixed test duration can be prescribed without knowing the assets and stream behaviour.
When testing a resampling path, confirm whether the audio is being decoded and re-encoded and listen for unintended changes. When testing a one-time offset, check the opening alignment and verify that the later offset remains steady rather than continuing to grow. When testing discontinuity handling, use the actual input and output format under which the boundary occurs. Preserve a copy of the original capture so that comparisons are not based only on memory.
For an always-on channel, make changes during a planned maintenance window if the test can interrupt viewers. If you cannot stop the public stream, reproduce the command on a short representative capture or a separate test output first. Keep the public feed’s established version and command available so you can revert if the test makes sync worse or creates a new issue.
The aim is not to accumulate flags until a number looks better. It is to learn whether a specific hypothesis explains a repeatable observation. If a setting changes the start offset but the drift still accumulates, that is useful evidence: it indicates the test affected one part of timing but has not answered the whole problem.
Record the command and compare results
Keep a small troubleshooting record with date, FFmpeg version/build, source asset identifiers, exact command, output protocol, receiving player, and the measurement checkpoints. Note which single change you made, what you expected it to affect, and what actually happened. This saves time when a stream is restarted, a file is replaced, or another person helps inspect the pipeline.
Compare both the direction and shape of the offset. “Audio late by about the same amount throughout” is more useful than “sync feels wrong”; “nearly aligned at the start, progressively later, then a further jump after the loop” is more useful still. You need not invent a precision your player cannot provide. The purpose is to make repeated observations comparable, not to manufacture exactness.
If the evidence does not narrow the cause, share a minimal reproducible case with the exact FFmpeg version, command, a short sample or clear description of the media, protocol, and measured behaviour. Remove private stream keys and credentials before sharing logs. Include whether the issue happens in a local output capture, the receiving platform, or both. Without those facts, an answer that claims a tested root cause is guesswork.
If the real problem is that your personal computer must stay awake to keep the feed running, rather than that audio and video diverge, StreamNeo can remove that specific operational burden: upload a video, provide your YouTube stream key, and the broadcast can run while your computer is off. That does not diagnose or repair FFmpeg timing in an existing pipeline, and it is YouTube-only.
For a persistent FFmpeg setup, consider the machine and stream process separately from media timing. A restart policy can help recover a stopped process, but recovery does not prove that playback remained synchronised. If you move the feed to a different host or alter how it is published, repeat the same baseline checks afterwards; a new runtime environment is not evidence of a sync correction.
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
What is the difference between a fixed offset and gradual audio drift?
A fixed offset is already present near the beginning and remains roughly steady as playback continues. Gradual drift starts close to aligned and grows over time. Measure at several points before choosing which timing behaviour to investigate.
Should I add aresample=async to fix my stream?
Not without checking the FFmpeg version, filter documentation, audio path and observed pattern. It is a possible line of investigation for gradual timing problems, not a proven fix for an unspecified command. Audio resampling changes how the audio is processed and may require re-encoding.
Can -copyts or a timestamp reset cause an audio-sync problem?
Those options can matter to timestamp behaviour, but their presence does not establish the cause in your feed. FFmpeg documents that a common shift preserves relative timestamp differences, and that -copyts affects automatic discontinuity correction in relevant formats. Check the actual format, options and measurements before changing them.
What details are needed to diagnose the problem properly?
Record the FFmpeg version and build, full command with secrets removed, media formats, output protocol, and whether drift occurs within a file or at a transition. Include measured behaviour at the start and later playback, plus whether a local output capture and receiving player agree. Without those details, a specific root cause or command would be speculation.