A sync problem on an FFmpeg YouTube live stream can be a fixed audio lead or lag, or it can grow gradually as the stream runs. Work out which pattern you have first; the cause may be timestamps, separate source clocks, frame-rate conversion, buffering or playback, and there is no single flag that fixes every chain.
Start by recording what the sources are, what the current command does, and when the mismatch appears. Then inspect timing, change one factor at a time and test for long enough with representative content before trusting the stream overnight.
First tell offset from drift
A constant offset means the audio is early or late by roughly the same amount at the beginning and later in the stream. A clap, a spoken consonant or a drum hit may make the mismatch easy to see. If the same event is still out of sync by about the same interval several minutes later, you may have a stable offset in the input or playback path.
Progressive drift is different: the mismatch grows as the stream continues. If speech begins close to the picture but is noticeably early or late later, suspect a timing relationship that changes over time, such as two independent clocks, irregular timestamps, or a conversion step that is not behaving as intended. Do not try to correct that with a fixed timestamp offset; a fixed adjustment cannot compensate for an error that keeps accumulating.
There are other patterns worth separating. A sudden jump can coincide with a reconnect, a source restart or a discontinuity in incoming timestamps. Intermittent stutter may look like sync trouble even when the underlying issue is buffering or dropped packets. Make a note of whether the issue begins immediately, appears gradually, follows a reconnect, or comes and goes.
Check more than one playback route if you can. Compare the encoder preview or a local recording with the YouTube playback, allowing for the player’s own buffering. If a local file is in sync but the live playback is not, the player or delivery path may be involved; if both are wrong in the same way, investigate earlier in the chain. A clear diagnosis starts with the symptom, not a guessed flag.
Map the sources and inspect their clocks
Write down whether video and audio come from one media file, one capture device, or separate sources. A file containing both tracks usually supplies timing information through its container and streams. By contrast, a camera and an audio interface may each run on their own clock. The title of the command or the fact that it uses FFmpeg does not tell you which situation applies.
Record the exact FFmpeg version and build, the input types, the current command, and any relevant capture or network path. Preserve the command before experimenting. Also note the intended output frame rate and whether the sound is live microphone audio, system audio, a file track or a network feed. Those details determine which timing assumptions are reasonable.
Inspect the input stream metadata and FFmpeg logs before changing timestamps. Look for missing, irregular, discontinuous or non-monotonic timestamps, and note when warnings appear relative to the audible or visible fault. Metadata alone does not prove that a source clock is stable, but it can identify obvious timing gaps or assumptions that deserve a controlled test. Keep a short log excerpt from a run that reproduces the problem.
FFmpeg has options that alter timestamp handling, including ways to preserve or generate timestamps and adjust offsets. They are not interchangeable repair switches. For instance, wall-clock timestamping makes a different assumption from trusting timestamps carried by the input. An offset is useful only when you have measured a stable lead or lag, and timestamp preservation is useful only when the source timestamps are the ones you intend to preserve. Avoid adding -copyts, wall-clock timestamping, offsets or asynchronous resampling indiscriminately; each changes the timing model and should follow evidence from your inputs.
If the audio and video are independent live sources and their mismatch grows, investigate whether they can be captured against a common clock or whether one source needs a source-specific rate correction. The right remedy depends on the capture chain. A correction that suits one device can make another source worse, so verify the result over a representative run rather than inferring the fix from the option name.
Check frame-rate conversion and buffering
Video frame timing is one part of the chain, but it is not the audio clock. FFmpeg’s output -fps_mode choices affect how video frames and their timestamps are handled. In broad terms, passthrough carries demuxer timestamps through; cfr duplicates or drops frames to meet a requested constant frame rate; and vfr passes timestamps or drops frames to avoid duplicate timestamps. These behaviours can affect motion and output timing, but none alone synchronises independent audio and video clocks.
| Mode | What happens to video timing | Trade-off to consider |
|---|---|---|
passthrough |
Demuxer timestamps are passed through | Keeps the source timing model, including irregularities that may be present |
cfr |
Frames can be duplicated or dropped to reach the requested constant rate | Gives a constant output cadence, but changes the frame sequence |
vfr |
Timestamps are passed through or frames are dropped to avoid duplicate timestamps | Avoids duplicate timestamps, but output intervals can vary |
Choose based on the source and the output you need, then inspect the result. If your source is already constant-rate, forcing a new rate may add needless duplication or dropping. If timestamps are irregular, preserving them can reveal rather than conceal the irregularity. The muxer may subsequently modify timestamps as well, so do not assume the input option is the last word in output timing. The FFmpeg documentation on frame synchronisation and timestamps describes these behaviours; match the option to the input rather than treating a mode as a general sync repair.
Buffering can confuse the diagnosis. An application, capture device, network input or player may hold data before passing it along. That can add latency or make symptoms appear in bursts, but a stable buffer delay is not the same as progressive clock drift. Record whether audio and picture remain consistently displaced, drift steadily, or jump when a buffer fills or a connection changes.
Avoid changing several queues, frame-rate settings and timestamp options together. If you alter buffering and frame timing at the same time, a better result does not show which change helped, and a worse result does not show which change caused it. Keep the original run as a baseline and use one change per test.
Use -re only when the input calls for it
FFmpeg documents -re as reading input at its native frame rate. It is mainly useful when you are sending a media file as though it were a live source: without pacing, a file can be read faster than real time, while pacing makes the reads follow real time. If you are building a stream from a recorded video, test whether pacing that file input is appropriate for your setup.
A live capture device or live network source is already producing data in real time. Adding a low read rate to that source does not make its audio and video clocks agree. FFmpeg warns that applying low read rates to actual capture devices or live streams can cause packet loss. The point is not that -re is always wrong; it is that its use depends on whether you are pacing a file or receiving a real-time source.
When a file is paired with a separate live source, think carefully about which input is being paced and what the two inputs’ clocks mean. Pacing the file does not synchronise it to an independent microphone or camera clock. It only controls how quickly FFmpeg reads that file. If drift grows between those sources, measure the relationship and address the source timing or capture method rather than assuming file pacing is a cure.
This distinction is especially useful when a command works for a local recording but fails for a live camera, or the reverse. Keep each input’s role clear in your command and notes. The guide to streaming a video folder continuously to YouTube describes a file-based use case; it is not a reason to apply the same pacing choice to live capture.
Review what FFmpeg sends out
Input timing is not the only timing that matters. Review the output settings and logs, including the chosen frame rate, audio sample rate, timestamp mode and muxing behaviour. Note whether FFmpeg reports duplicated or dropped frames, timestamp discontinuities, warnings, or output pauses around the moment sync changes. Treat a log as evidence to compare across controlled runs, not as an automatic diagnosis.
YouTube’s live encoder guidance recommends CBR bitrate encoding, lists AAC or MP3 for audio, and recommends a two-second keyframe frequency without exceeding four seconds. It also gives sample-rate guidance of 44.1 kHz for stereo and 48 kHz for 5.1 surround. These are delivery recommendations, not a guarantee against source-clock drift. Check the current YouTube live encoder settings before setting up a broadcast, since platform guidance can change.
Keep platform compatibility separate from sync diagnosis. A compatible codec, bitrate mode or keyframe interval can help the delivery stream meet YouTube’s guidance, but does not repair an audio source whose clock runs at a different rate from the video source. Likewise, changing bitrate is not a timing fix unless your evidence points to a specific delivery or processing problem.
For playback observation, FFplay can show synchronisation drift statistics and identifies clock behaviour that may help you compare streams. Consult the FFplay documentation for its display and sync options. Compare the same identifiable event at the start and later in the run, and note whether the reported behaviour agrees with what you hear and see. A player’s display is one diagnostic view, not proof of where the fault originates.
If the stream is technically live but the viewer sees the wrong event timing, also rule out content or loop behaviour. For a file-based channel, confirm the intended sequence and transitions with a check that a YouTube stream is actually looping. That will not solve clock drift, but it can prevent a content-handling fault from being mistaken for a sync fault.
Test with the content and duration you expect
Do not rely on a few seconds of opening footage. A test should include speech, visible movement and any audio pattern that makes alignment easy to judge, such as a clap or a beat. Run it long enough to see whether a small initial mismatch remains stable or grows. There is no universal duration that proves every source stable; the test should reflect how long you plan to run and the conditions that have caused trouble.
YouTube advises testing with similar audio and movement and monitoring stream health and event messages. Run a private or otherwise appropriate test stream before the public event, then review both the encoder output and YouTube’s status messages. If the live player adds delay, distinguish delivery latency from audio being out of step with the picture. Record what was tested so that a later change can be compared fairly.
Include the conditions that matter in actual use: the intended resolution and frame rate, the real audio source, expected network path, and any transitions or reconnects that the channel will encounter. A quiet still image does not reveal the same problems as a moving scene with speech. If the stream will run overnight, test beyond the point at which drift has previously appeared rather than judging it only from startup.
A useful test record is simple: version and build, source types, command, output mode, start time, observed offset at the beginning, later observation, and any warnings or reconnects. Save a local recording if practical, because it lets you compare the encoded result without relying only on a live player. Avoid claiming success from a single short check if your real concern is a fault that appears after hours.
For a small channel assembled from a prerecorded loop, you may decide that removing the need to keep a computer running is more important than maintaining a custom FFmpeg chain. StreamNeo can remove that particular computer-running burden by taking an uploaded video and running it as a YouTube live stream, but it does not replace diagnosis of a live capture setup or change YouTube’s requirements. If you need camera and microphone inputs, keep testing that chain on its own terms.
Change one factor and narrow the cause
Once you can reproduce the symptom, change one thing at a time. Start from the saved command and test a single timing hypothesis: whether the source timestamps are irregular, whether an output video frame mode is introducing drops or duplicates, whether a file should be paced, or whether an independent source clock is responsible. Keep a note of the result and revert before testing the next hypothesis.
Use the symptom to choose what to inspect. A stable offset invites measurement and a carefully validated fixed adjustment. Growing drift points towards a rate or clock relationship, not a one-time offset. A jump after reconnect suggests examining discontinuities and what each input reports at that point. Stutter with no changing audio-picture relationship may call for investigating buffering, packet loss or overload separately.
If a correction improves the opening but worsens the end, it is probably compensating for the wrong thing. If changing -fps_mode changes judder but not the audio drift, keep those conclusions separate. If pacing a file helps file playback but a capture source starts dropping packets, remove that setting from the capture input and revisit the source path. These outcomes are useful even when they do not produce a final fix, because they narrow the problem.
When sources use independent clocks, consider whether a common-clock capture path is available or whether a source-specific resampling or rate correction can be measured safely. Do not choose a correction only because a command appears frequently online. The FFmpeg manuals define options, but they cannot identify a reader’s device, capture chain or actual timestamp quality from a title alone.
If you are maintaining a long-running loop, also separate sync reliability from process reliability. Restarting a stream after a broken connection is a different problem from correcting drift while it runs; the FFmpeg broken-pipe troubleshooting guide concerns that separate failure mode. For a channel that depends on a local computer staying on, the power-cut continuity guide covers another operational risk, not a sync adjustment.
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
Can I fix every sync problem with a timestamp offset?
No. An offset can address a measured, stable lead or lag, but it cannot correct drift that grows over time. First compare the mismatch near the beginning and later in the stream.
Does -re synchronise audio and video?
No. It paces reads, principally for a file used as a live source. It does not reconcile independent live clocks, and FFmpeg warns that low read rates on capture devices or live streams can cause packet loss.
Which -fps_mode should I use?
It depends on the timestamps and frame-rate behaviour of your source, and what output cadence you need. passthrough, cfr and vfr handle video frames differently; none is a universal correction for audio-clock drift.
What should I check before streaming to YouTube?
Test with representative speech and movement, review FFmpeg’s output and logs, and monitor YouTube’s stream health and event messages. Check YouTube’s current encoder guidance for delivery settings, but do not treat those settings as a cure for source timing problems.