Audio sync problems usually fall into two different categories: a fixed delay, where the audio is early or late by roughly the same amount, and drift, where the gap grows as the livestream continues. You need to identify which one you have before changing an FFmpeg option.
A measured offset can correct a measured starting delay. It cannot repair two input clocks that continue to move apart. The practical path is to observe the error, inspect timestamps and clock sources, apply the narrowest correction, and test the complete streaming path before relying on it overnight.
Identify whether the audio is early, late, or drifting
Start by watching a local preview or the actual YouTube broadcast with something easy to judge. A person speaking, a handclap, a drum hit, or a door closing gives you a visible event and a matching sound. Write down which arrives first and approximately how large the gap appears to be.
Do not rely on a single moment. Check near the start of the stream, then check again after the stream has been running. If a clap is consistently heard after the hands meet, the audio is late. If it is heard before the visible event, the audio is early. If the relationship is stable at the beginning but noticeably different later, you are measuring drift rather than a simple offset.
A fixed error might look like this: speech is about the same distance ahead of the speaker at the beginning and near the end. Drift looks different: the speech begins close to the lips, then gradually leads or trails them. The distinction matters because delaying an input by a constant duration changes the starting point only.
For a local check, ffplay can show synchronisation information in its statistics. The FFmpeg ffplay documentation describes -stats as reporting audio/video synchronisation drift and documents audio as the default master clock. That makes it useful for observing playback behaviour, but it does not tell you which capture device, timestamp, or clock created the error.
Make a short record rather than relying on memory:
| Observation | What to record |
|---|---|
| Direction | Audio early or audio late |
| Starting error | Approximate gap at the beginning |
| Later error | Approximate gap after the test has run |
| Behaviour | Constant, changing slowly, or changing suddenly |
| Test path | Local preview, YouTube preview, or public broadcast |
This also helps you avoid blaming input order without evidence. A historical FFmpeg-user report described audio delay after changing the order of a webcam and PulseAudio input, but that was one setup, not proof that placing audio before video generally causes desynchronisation. Reproduce the observation in your own command before changing its order.
Check input timestamps and clock sources
Before adjusting a command, preserve the exact FFmpeg version, complete command line, input order, input formats, stream mapping, reported start times, and warnings. Keep the uncut console output. A shortened command can hide the option that changes timestamps, while a missing log line can hide an input that starts later than the other.
The source matters as much as the file or device name. A webcam may produce video according to one device clock, while a separate audio interface or PulseAudio source follows another. Even when both are labelled with the same nominal frame or sample rate, their timing can differ during a long capture. That difference may appear as growing drift rather than an obvious failure at startup.
Look for these questions in the input information and logs:
- Does each input have a usable start timestamp?
- Are the timestamps based on the same clock source?
- Does one device report a different time base or format than expected?
- Are the audio and video streams being mapped as intended?
- Are timestamp warnings appearing when the stream runs?
- Does a timestamp-preservation option already affect the command?
FFmpeg's -isync documentation states that it adjusts an input's timestamps by the difference in start times relative to a reference input. It also says that the source timestamps of the two inputs should derive from the same clock source for expected results. If a starting timestamp is absent, no adjustment is made.
Read the official FFmpeg command documentation for the version you actually run. Options can be sensitive to their position in the command, and input-scoped options need to apply to the input they are intended to affect. Do not copy a timestamp option into a long production command without checking which input it precedes.
The clock question is especially important for a camera-and-microphone setup. If the camera and audio device are independent, a neat start-time relationship does not prove that they will stay aligned. If both inputs are generated or captured against a shared timing source and have valid start timestamps, an input synchronisation option may be meaningful. If they do not, you may need to investigate the capture arrangement or how FFmpeg is handling the audio over time.
You should also separate capture symptoms from delivery symptoms. If the local preview already drifts, the problem is likely before YouTube receives the stream. If the local output is aligned but the delivered broadcast is not, compare the encoded output and the viewing path before changing capture timestamps. Network interruptions and reconnects can complicate the observation, so save the relevant logs rather than treating every later mismatch as a clock problem.
Understand which FFmpeg sync option fits
FFmpeg options that mention timestamps are not interchangeable. Each changes a different part of the timing relationship, and each has conditions that affect whether it is appropriate.
| Situation | Candidate action | Main limitation |
|---|---|---|
| Audio has a fixed, measured delay | Use -itsoffset on the input that needs to move |
A wrong sign or wrong input increases the error and does not fix continuing drift |
| Separate inputs share a clock and have valid start timestamps | Consider -isync with a reference input |
Expected results depend on the shared clock and available start timestamps |
| You need to observe playback drift | Use ffplay statistics |
It shows behaviour but does not identify the root cause |
| The gap changes during operation | Inspect clocks and timestamp progression before changing filters | A historical filter example is not a universal prescription |
-itsoffset adds a time offset to the timestamps of the input it precedes. A positive value delays that input by the stated duration. This is a direct way to move one stream when the measured error is constant.
-isync is different. It uses the difference between input start times relative to a reference input, rather than applying a duration that you chose from a playback observation. That makes it relevant only when the inputs provide the timestamps and clock relationship it expects. If either input lacks a start timestamp, adding -isync does not create one.
The interaction with -copyts also matters. FFmpeg's documentation specifies that -start_at_zero must also be set when using -isync with -copyts. Timestamp-preservation options can alter the way FFmpeg processes input times, so add them because your diagnosed timing model requires them, not because they appear in someone else's command.
A useful rule is to change one timing variable at a time. First establish whether the error is fixed or growing. Then choose an option whose documented behaviour matches that observation. Finally, measure again using the same event and test path. If several options are changed together, you may get a better-looking preview without knowing which change caused it or whether it will hold during a longer broadcast.
Correct a fixed audio offset
Use a fixed offset only when your measurements show a fixed offset. If audio is consistently early, delaying the audio input may bring the streams together. If audio is consistently late, delaying it further makes the result worse; you would need to consider whether the video should be delayed or whether the input relationship should be changed in another way.
The basic illustrative shape is:
ffmpeg -i video_source -itsoffset OFFSET -i audio_source \
... output
Here, OFFSET is a measured duration, and the placement shown is part of the example. The option applies to the input it precedes. Replace the placeholders with your actual inputs and output settings, then confirm the sign and affected input in the documentation for the FFmpeg build you use.
Do not treat this as a ready-to-run command. The correct value depends on the capture devices, their reported timestamps, the input order, the output path, and the direction of the error. A value copied from a different webcam, microphone, operating system, or capture format has no reason to match your setup.
After applying the offset, repeat the same test. Check a visible event near the beginning and later in the run. If the result is aligned initially but separates over time, the offset was not a complete solution. It may have hidden the starting error while leaving the underlying clock difference untouched.
It is also worth testing the output produced by the exact command used for YouTube, not only an isolated local file. A local preview can use different buffering and clock behaviour from the encoded output sent to the platform. If your channel is based on a long prerecorded loop, inspect the loop boundary as well. A discontinuity or timestamp reset at the join can look like an audio sync fault even when each individual segment is aligned.
For people running devotional or music channels, a steady beat is a good test signal because a small timing change is easy to hear against a visible tabla hit or handclap. For a study or news channel, use a presenter speaking while making a clear hand movement. Choose an event that you can repeat rather than judging an entire programme from memory.
Address continuing drift
When the gap grows, stop increasing or decreasing a fixed offset and investigate the continuing timing relationship. A constant timestamp adjustment changes where the streams begin. It does not force two independent clocks to agree for the rest of the broadcast.
Compare the observed error at several points. If the audio leads by a small amount at the start and substantially more later, record that change with the elapsed test period, but do not turn it into a universal drift rate. The result belongs to your particular devices, formats, operating system, FFmpeg version, and command.
Inspect whether the audio capture is actually running at the rate FFmpeg expects. Check the device's reported format, timestamp progression, buffering messages, and any warnings about dropped, duplicated, or irregular frames. Review the video side too. A video capture source that changes cadence can make a stable audio stream appear to be drifting.
If the sources do not share a clock, consider whether the capture arrangement can be simplified. A single source that already contains aligned audio and video removes one relationship that must be maintained. That may not be possible for a webcam and separate microphone, but it is a useful diagnostic comparison. If a combined source stays aligned while separate devices drift, the timing relationship between the devices deserves attention.
You may encounter examples using an audio resampling filter such as aresample=async=1. A historical FFmpeg-user discussion included that kind of example, but it is not evidence that the setting is a universal live-stream fix. Resampling can alter audio timing and may have side effects, so validate the filter's behaviour against your FFmpeg version and the symptoms you measured. Do not add it simply because a command on a forum appeared to work for someone else.
Test any correction for longer than the point at which the problem normally becomes visible. A command that looks correct for a short clip may still drift through a night. Keep the test focused: change the suspected clock or timestamp handling, run the same source, observe the same events, and compare the beginning with the later part. This is slower than stacking options, but it leaves you with a diagnosis you can repeat.
If your wider setup is also losing its RTMP connection, solve that separately. The troubleshooting steps in how to troubleshoot RTMP connection errors in an FFmpeg YouTube stream can help distinguish a transport interruption from an audio timing fault. A reconnect may restart timestamps or playback state, so note exactly when the sync changes.
Test the complete stream before going live
Run a controlled test before putting the command on an always-on channel. Use the actual inputs, the actual mapping, the intended output command, and the same viewing route you expect to use during the broadcast. If the test uses a substitute microphone or a short local file, label that limitation clearly; it does not validate the production capture path.
Start with a visible and audible event. Note the initial relationship, then repeat it after the stream has been running. Watch for a constant delay, a growing gap, a sudden jump, or a change after a reconnect. Save the command and complete console output with the observations. If you need help later, those details are more useful than a description such as “the audio slowly goes out of sync”.
Keep the test variables small:
- Establish the unmodified behaviour.
- Change one timestamp or sync setting.
- Repeat the same event-based check.
- Compare the beginning and later observation.
- Keep or remove the change based on the result.
Do not use input order as a substitute for diagnosis. If moving the audio input changes the result, record that fact and investigate why the timestamps or device initialisation differ. It may be a useful change for your particular setup, but it is not a general FFmpeg rule.
If the channel is based on a prerecorded file rather than live capture, check the file before building a continuous broadcast around it. A file with audio already out of sync needs a different remedy from two live devices with different clocks. For a channel using a long playlist, inspect transitions, silence, and any change in sample rate between files. You can also review how to set up FFmpeg for a 24/7 YouTube stream on Amazon EC2 for the broader operational concerns around running a command continuously, while keeping audio diagnosis separate from hosting choices.
For a channel that should run without your computer remaining on, an uploaded file can remove the need to keep a local capture process alive. StreamNeo is useful here when the specific problem is maintaining a prerecorded file as a continuous YouTube broadcast after you have checked the file's own audio alignment. It does not turn a badly synchronised source into a correctly synchronised one, so inspect the media first.
If your content is music-led, also separate synchronisation from rights and source quality. The article on whether you can use Spotify songs in a 24/7 YouTube radio stream covers a different risk from timestamp drift, but both should be checked before you commit a long-running channel to an unattended setup.
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
Should I delay audio if it is out of sync?
Only if testing shows a fixed audio lead and the audio input is the stream that needs to move. A positive -itsoffset delays the input it precedes, so a wrong sign or wrong target can increase the error. If the gap grows during the stream, investigate drift instead of treating a fixed offset as the cure.
Does putting the audio input before the webcam cause desynchronisation?
Input order alone is not a general explanation. A historical report described a delay in one webcam and PulseAudio setup, but the result may depend on the devices, timestamps, clock sources, and command. Reproduce and measure the behaviour in your own setup before reordering inputs.
When should I use -isync instead of -itsoffset?
Use -isync only when the inputs have usable start timestamps and their timestamps derive from the same clock source, as required for expected results in the FFmpeg documentation. Use -itsoffset for a measured, constant timing adjustment. Neither option should be selected without checking which input is early or late and whether the error changes over time.
Can a local preview prove that YouTube will stay synchronised?
No. A local preview can reveal whether the capture and encoding path is already drifting, but the complete delivery path may behave differently. Test the actual command and observe the broadcast path, preserving logs so that reconnects, timestamp warnings, and stream changes are not mistaken for one simple sync problem.