If FFmpeg audio is out of sync on an EC2 YouTube live stream, first find where the mismatch begins and whether it stays constant or grows over time. A measured fixed offset and progressive drift point to different investigations, so do not start by adding an offset or switching timestamp modes.
Compare a short local or encoded sample with the YouTube playback, then check the source, FFmpeg output and viewer experience separately. Without your command, source topology and measured offset, there is no universal command or EC2-specific root cause to prescribe.
Describe the sync problem and when it begins
“Out of sync” can describe more than one problem. A viewer may hear speech before the speaker moves, see a mouth move before hearing the words, or simply see the whole broadcast arrive later than expected. The first two are audio-versus-video alignment problems; the last may be live latency. Treat them separately.
Choose a repeatable reference in the programme: a clap, a sharp drum hit, a door closing, or a spoken word paired with a visible mouth movement. Record whether audio leads or trails video, when the mismatch is first noticeable, and whether it changes during a continuous sample. Avoid judging from memory across separate playback sessions: seeking and playback buffering can make comparisons unreliable.
Check the earliest useful point in the chain and a later point. If the source inputs are already misaligned, changing an output option may hide the problem in one sample without fixing its cause. If an encoded local output looks aligned but YouTube playback does not, investigate contribution, stream health and playback conditions before rewriting the source timing.
Write down the exact FFmpeg command and version or build, input types, input start times, stream mappings, frame rate, sample rate and timestamp-related options. Keep a short sample with a visible and audible reference. This is not paperwork for its own sake: it lets you compare like with like and undo a change that made the result worse.
Fixed offset or progressive drift
A fixed offset is a similar lead or lag at the start and later in the sample. For example, a clap may look late by roughly the same amount near the beginning and end. That pattern makes initial timestamps, different input start times or a consistent processing delay worth inspecting. It does not prove which of them is responsible.
Progressive drift means the difference grows or shrinks during playback. If the clap is nearly aligned at first but noticeably displaced later, investigate ongoing timestamp continuity and whether audio and video clocks or rates are behaving differently. A single fixed shift can align one instant, but it cannot correct a mismatch that keeps accumulating.
| What you observe | First investigation | What not to assume |
|---|---|---|
| Similar offset at the beginning and later | Input start times, initial timestamps and consistent processing delay | That an arbitrary offset will fix every output |
| Increasing or decreasing separation | Timestamp continuity, rate behaviour and separate source clocks | That one fixed offset can stop continuing drift |
| Local output aligns, YouTube playback differs | Ingest health, playback conditions and whether all viewers see it | That the source file or FFmpeg filter is necessarily wrong |
| Only some viewers report a delay | Viewer buffering, latency mode and network conditions | That all reports describe an A/V sync error |
Make the distinction with a few samples from one continuous programme, not a single still frame. Note the approximate direction and pattern without claiming more precision than you measured. If you cannot tell whether the error grows, capture a longer sample under the same conditions before choosing a fix.
Check source timestamps and clocks
Next ask whether audio and video come from one source or separate sources. A file with audio and video together is different from a webcam, capture input or other video source paired with separately captured audio. With separate inputs, their timestamps may begin from different origins or follow different clock behaviour. This is a hypothesis to test, not a finding that applies to every EC2 stream.
Inspect the input order, input start times and mapping in the actual command. Confirm that the audio and video streams you intend to publish are the ones being selected. A mistaken -map can put an unexpected stream into the output, while an unintended start-time difference may produce an initial gap or offset. Changing argument order is not a general fix: one FFmpeg-user report described a delay in a particular webcam and PulseAudio setup, but that anecdote does not establish a general rule or an EC2 cause. See the reported FFmpeg-user case only as an example of why the actual input arrangement matters.
Look for discontinuities or irregular timestamps in the inputs and in any local output you can inspect. Note whether the issue appears after a reconnect, loop boundary or source change. If it occurs at the same transition each time, that clue differs from drift that accumulates steadily throughout a single uninterrupted segment.
FFmpeg’s manual documents -copyts as a way to retain input timestamp values rather than applying its normal sanitising behaviour. Retaining timestamps can preserve useful timing, but it can also carry a source problem forward. Do not add it simply because sync is wrong; first establish whether the input timestamps are valid for the output you need. The FFmpeg command-line documentation explains timestamp-related options and their scope.
Inspect encoder timing and processing
Once source behaviour is understood, inspect how FFmpeg turns those inputs into the output. Check the exact stream mapping, output frame-rate behaviour, sample rate, audio encoder and any filters or timing options in the command. Change only the option tied to the suspected cause, and preserve the working command so you can revert it.
The FFmpeg manual describes -itsoffset as an input time offset. It can be relevant when you have measured a stable offset and identified which input needs adjustment. It is not a repair for growing drift: shifting an input changes its placement, not the ongoing rate relationship. If you test it, document the measured direction, the stream to which the input belongs and whether the offset improves both the beginning and later sample points.
The same manual describes -fps_mode as a per-output-video-stream choice. Its modes govern whether timestamps are passed through, adjusted to a constant rate, or handled to avoid duplicate timestamps; the muxer may still modify timestamps later. A frame-rate mode can affect video timing, so changing it without checking frame-rate behaviour may add a new variable rather than solve audio alignment.
-re or -readrate 1 controls reading an input at its native rate and can be useful when controlling input flow for a file-based live output. FFmpeg warns against using a low read rate on actual capture devices or live streams because packet loss may result. Do not add -re reflexively to a real-time source. The distinction between a file being paced for output and a live input already arriving in real time matters.
Use YouTube’s encoder recommendations as a compatibility baseline, not as a sync diagnosis. Its encoder settings guidance recommends CBR, AAC or MP3 audio, a two-second keyframe interval that should not exceed four seconds, and audio settings by channel layout. For advanced settings it lists 44.1 kHz stereo or 48 kHz 5.1, with 128 kbps stereo or 384 kbps 5.1. These recommendations may help you check a contribution setup, but they do not align mismatched timestamps automatically.
If your command sends RTMPS, verify the protocol, endpoint and path, port, hostname and TLS SNI against YouTube’s RTMPS ingest guide. Those checks address connection errors and ingest configuration, not a direct audio-sync correction. An ingest connection that stays healthy does not by itself prove the audio and video timestamps are aligned.
Separate ingest issues from viewer buffering
Compare the local encoded output with playback from YouTube. If both show the same audio lead or lag, the problem is likely present before or during encoding, so return to source timing and the FFmpeg processing path. If the local output is aligned and only YouTube playback appears wrong, gather more evidence before changing the command: check YouTube stream health, compare a controlled playback sample, and ask whether the same behaviour occurs for other viewers.
A stream reaching viewers later than expected is not necessarily audio out of sync. YouTube explains that lower latency uses less read-ahead buffer, which can make viewers more likely to notice encoder or player problems. Congestion and other conditions can also delay a live stream even when average network capacity appears adequate. Its latency guidance describes service-level latency, not acceptable A/V sync tolerances: it says most viewers on low-latency streams experience latency under 10 seconds and most on ultra-low latency under 5 seconds, while ultra-low latency carries greater buffering risk. Those descriptions do not set a target for lip-sync accuracy or guarantee what a particular viewer will experience.
Ask whether reports come from one device, one network, or more than one viewer. A delay that differs between devices can arise from playback or network conditions; a consistently displaced clap in the local output points elsewhere. Do not use a timestamp filter to compensate for a viewer’s changing buffer unless you have shown that the encoded A/V relationship itself is wrong.
If stream health shows connection trouble, deal with that separately from alignment. RTMPS endpoint, TLS or timeout checks may explain an ingest warning, but a warning-free connection is not proof that source timestamps are correct. For other interruptions that accompany the timing complaint, the broken-pipe troubleshooting guide covers a different failure mode and should not be mistaken for an A/V sync diagnosis.
Measure before applying an offset
Before editing the command, make a small evidence sheet. Include the reference event, whether audio leads or trails, approximate separation at the first and later observation, whether the change is stable or growing, and where each sample was captured. Note if the same mismatch appears in source inputs, local encoded output and YouTube playback. If you cannot inspect the source directly, say so rather than treating the local output as proof of what happened upstream.
For a fixed offset, test whether a measured input shift improves the reference near both the start and the end. For progressive drift, compare how the separation changes over time and inspect timestamp and rate behaviour; a fixed shift might improve the first event while leaving the last worse. Avoid guessing an offset based on a single playback impression. If the direction is uncertain, collect a clearer sample before editing.
For prerecorded or file-driven channels, also note whether the mismatch repeats at a loop boundary or after a restart. That can distinguish a transition-specific timestamp issue from a continuous rate difference. If your wider goal is to keep a channel running continuously from a cloud machine, the cloud-server setup guide provides broader operational context, but it does not diagnose this particular sync symptom.
StreamNeo can remove the need to leave a personal computer running for a file-based always-on YouTube broadcast, which addresses the overnight burden of keeping that machine available; it does not replace measuring an existing FFmpeg-to-EC2 timing problem. For an FFmpeg workflow you control, keep diagnosis tied to the actual inputs and output rather than assuming that moving the broadcast elsewhere corrects its timestamps.
Retest one change at a time
Keep a copy of the original command and change a single relevant setting per test. Use the same source segment and reference event, then compare the same stages and playback conditions. Record what changed and whether the mismatch became smaller, stayed stable, grew or moved to another point. If a change has no clear result, revert it before testing another hypothesis.
For a measured fixed offset, a controlled -itsoffset test may be reasonable when you know which input should move. For drift, prioritise source clock and timestamp continuity, stream mapping and frame-rate handling. Do not combine an offset with a timestamp-preservation or frame-rate change in one experiment: even if the output improves, you will not know which alteration mattered.
When comparing local output and YouTube, wait for each sample to play under comparable conditions and check more than one viewer if possible. A single viewer’s buffer can change between attempts. If the issue is limited to YouTube, review stream health and latency settings before touching the source; if it is already present locally, continue upstream.
After a change, run a pre-event test using audio and movement similar to the real programme, then monitor stream health during the test. YouTube recommends this sort of testing in its encoder guidance. Keep a note of the command, FFmpeg version, source arrangement and measured behaviour, especially if the broadcast has to run overnight. If the result remains ambiguous, provide those details when asking for help rather than requesting a generic sync command.
For a channel built around a repeating video or a playlist, verify that alignment persists across the hand-off as well as within one clip. The separate guide to playing the same video file all day discusses the continuous-play question; for this issue, the useful point is to test the loop transition independently from ordinary playback.
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 should I check first when FFmpeg audio is out of sync?
Establish whether the offset is fixed or grows, then compare the source or local encoded output with YouTube playback. Note which direction the audio leads or trails and whether other viewers see the same result. Do not apply a guessed offset before you know where the mismatch first appears.
Can -itsoffset fix audio that drifts over time?
It can be tested for a measured, stable input offset, but a single shift does not correct an ongoing rate or timestamp mismatch. If separation grows, inspect source clocks and timestamp continuity first. Confirm any change at more than one point in the same sample.
Is EC2 the cause of YouTube audio sync problems?
The symptom alone does not identify EC2 as the cause. Source timestamps, separate input clocks, FFmpeg processing, ingest conditions and viewer buffering are distinct possibilities. You need the actual command, source arrangement and measurements to narrow them down.
How can I tell viewer latency from A/V desynchronisation?
Latency is how late the live programme arrives; A/V desynchronisation is the relative alignment of sound and picture within the programme. Compare a reference event in local output and YouTube playback, and ask whether the same mismatch appears for other viewers. A delayed stream can still have audio and video aligned.