When audio and video lose sync in a looping FFmpeg stream, first work out whether the error stays constant, grows during playback, or changes at the loop boundary. Those patterns call for different checks; none identifies the cause on its own.
Measure what is happening on the actual outgoing stream before changing timestamps. FFmpeg options such as input looping, real-time pacing and timestamp offsets affect different parts of the process, and no single command can be prescribed as a guaranteed fix without the file, FFmpeg build and trace.
Identify the kind of sync problem
Start with a repeatable event that is easy to recognise: a handclap, a spoken word beside a visible mouth movement, or a sharp musical beat aligned with a cut. Note whether the sound arrives before or after the visible event. Then check again later in the same play-through and just after the next loop begins.
A steady lead or lag points to a different investigation from a mismatch that gradually increases. A jump that appears at each restart suggests checking the transition between the end and start of the file. Choppy sound, dropped pictures or pauses may indicate a delivery or encoding problem rather than a simple timestamp offset. These are useful classifications, not diagnoses: a file or log is needed to establish what is happening in a particular setup.
Write down the symptom in plain terms. For example: “The clap is about the same distance late at the beginning and near the end,” or “It matches at the beginning, then the picture gets further ahead.” Avoid writing only “out of sync”; that description does not tell you which layer to test.
Keep the comparison conditions the same. Use the same source file, the same playback point and a recognisable event. If you change the encoder, filter chain and offset together, a better result will not tell you which change mattered. Make one controlled change at a time, and keep the original command so you can return to it.
If the main uncertainty is where a repeated video begins rather than whether sound and picture match, the separate guide to starting a YouTube Live loop at a specific point in a video may help you inspect the loop itself. A chosen start point does not, by itself, resolve a timing mismatch.
Check whether the offset grows over time
Compare the same kind of event near the start and later in one play-through. It need not be a laboratory measurement: a recording of the outgoing preview can help you judge whether the gap appears unchanged or has visibly widened. Record the approximate playback time and what you observed. Avoid judging from a single scene change, because the edit itself may not align sound and picture precisely.
A nearly unchanged gap is consistent with a constant offset. A gap that changes progressively is drift, which may involve how the source timelines, timestamps, sample rate or frame cadence behave over time. The pattern narrows the investigation but does not prove which factor is responsible. In particular, adding a fixed timestamp offset cannot be assumed to repair an error that accumulates as the stream runs.
Inspect the source before trying to compensate for it. Use ffprobe to review the audio and video stream details, including start times, durations, frame rates and audio sample rate, and compare those values with the intended timeline. Check whether the picture and sound actually belong together throughout the source. A file can have plausible stream metadata and still contain content that is already misaligned.
Look at timestamps as well as durations. Two streams may start at different times by design, or their reported durations may not reflect the useful content at the end. If the mismatch is already present in the source file, a change to live-output pacing will not make its timeline correct. If it emerges only after repeated playback, look closely at what happens as FFmpeg returns to the start.
For a channel assembled from prerecorded material, it is useful to keep source preparation separate from delivery. The guide to streaming a 24/7 Indian music radio-style channel from prerecorded videos covers the broader channel workflow; the sync check here is about confirming that each piece of media retains its intended audio and video timing.
Inspect what happens at the loop boundary
Watch the end of one play-through and the first moments of the next. Listen for a cut, a pause, a repeated syllable or a sudden change in the sound-to-picture relationship. Check whether the picture also jumps, freezes or repeats. A boundary problem can be hard to spot if you only test the middle of a clip.
With -stream_loop -1, FFmpeg repeats an input indefinitely, but that alone does not guarantee a seamless or synchronised boundary. The last usable audio sample and video frame may not describe the same moment; streams may have different durations; and timestamp behaviour at the restart depends on the media and processing choices. The loop option does not repair an edit that was not prepared to loop cleanly.
If the relationship is right within each play-through but jumps when the file restarts, treat that as a boundary symptom rather than immediately applying one offset to the entire input. Check the source end and start, the stream durations and their timestamps. A very short test that includes several boundaries can be more informative than watching a long stretch from the middle.
A boundary can also look worse when the clip’s ending is abrupt. For example, the sound might fade out while the picture holds on a final frame, then both return immediately at the start. That may be an editorial transition rather than gradual timestamp drift. Decide whether the source should have a gap, crossfade or hard cut before changing stream timing; those are different creative choices.
For a channel built around stories or a prepared playlist, repeating a single file is not the only programming model. The article on creating a 24/7 YouTube story stream from an unlisted playlist is relevant if you are comparing how to organise the material. It does not replace testing the audio and picture at each transition in the output you plan to broadcast.
Use input looping and real-time pacing carefully
For prerecorded file-to-live output, FFmpeg’s -stream_loop input option and -re pacing option may both be relevant. The first controls repetition of an input; the second paces reading so a file is sent at its native rate for real-time output. They do different jobs. Pacing is not a synchronisation correction, and looping is not proof that every loop boundary will be seamless.
Option placement matters. Input options generally need to appear before the input they affect, while output options belong near the output they govern. Consult the documentation for the installed build rather than copying a command from a different version. The online FFmpeg documentation explains the available options, but your own ffmpeg -version and relevant option help are important when assessing the behaviour of the binary you actually run.
The documentation describes -re as reading input at its native frame rate, equivalent to setting -readrate 1. That is useful context for a file being used as a live source. Its warning about low read rates is especially relevant to genuine capture or live inputs: slowing down an input that must be consumed in real time can lead to packet loss. Do not add a low read-rate setting indiscriminately to solve a file-to-live sync issue.
A schematic command is not a safe universal recipe. The input format, streams to map, chosen codecs, frame rate, filters and installed build all matter. If you examine an example, treat placeholders as placeholders, verify each option against your build, and never paste a real YouTube stream key into a public issue or log. FFmpeg’s -shortest is also not a general solution for an indefinite stream: it ends output when the shortest output stream ends, which can be contrary to the aim of continuous delivery.
Keep the first test simple enough to interpret. If you are checking pacing, do not also change the frame-rate mode and apply an offset. Save each command and its result. A setting that makes one test look better may have changed duration, frame cadence or delivery timing without fixing the source relationship.
Measure before correcting an offset
Only consider an offset after establishing that the error is approximately constant. Measure which stream leads and by how much using a repeatable event in a representative test. Be clear about the direction: “audio is ahead of the picture” is more useful than “add a delay” until you have checked how the option expresses that change.
FFmpeg’s -itsoffset adds an offset to input timestamps. It can be relevant to a measured fixed difference, but it is not a general audio repair switch. Its placement and sign matter, and a change to one input’s timestamps can alter how that input lines up with the other streams. Check the manual for the installed version and verify the effect in a test; do not borrow an offset value from somebody else’s file.
Do not use a fixed offset to treat drift that grows through playback or a jump at each loop. Those symptoms call for checking the source timeline, timestamps, sample rate, frame cadence and boundary behaviour. A constant shift may make one point appear right while leaving later playback worse. Likewise, do not assume a filter or an -async setting is appropriate without evidence and version-specific documentation.
Frame-rate synchronisation is a separate decision from audio timing. FFmpeg’s -fps_mode options govern how video frames are handled: for example, constant-frame-rate output can duplicate or drop frames to reach a requested cadence. That can affect motion and timestamps, and muxer processing may further change timestamps. It is not a universal audio-sync switch. Choose a mode only after deciding what output frame cadence you need and testing the result.
Keep a brief change record: the original symptom, the measured lead or lag, the single change made, and the result at the beginning, later in the play-through and at the loop boundary. That makes it easier to undo a change that only masks one point. It also helps another person review the issue without guessing which command produced which observation.
Test the actual outgoing stream
A local preview or a command that runs without an error is not enough. Test the signal as it reaches YouTube, because encoding, muxing, network delivery and platform preview are all part of the path your viewers use. In Live Control Room, check a section with both movement and sound, then observe it again after the stream has run and crossed a loop boundary.
YouTube Help recommends testing before going live with audio and video movement similar to what the planned stream will contain. Its live encoder settings guidance lists supported ingest details and recommends a two-second keyframe interval, with a maximum of four seconds. These are ingest guidelines, not a way to correct a source timeline that is already misaligned. The guidance also lists audio sample rates for stereo and surround configurations; use the current page for the settings applicable to your stream rather than treating one setting as a sync fix.
During the test, look at the Live Control Room preview and stream-health messages. A connected indicator says that an ingest is reaching YouTube; it does not establish that the audience hears and sees matching events. If the picture stutters or the sound breaks up, note that separately from a steady lead or lag. YouTube’s live streaming help is the place to check current platform instructions and stream-health guidance.
Use a representative segment, not only a static title card. Include speech, a beat, or a visible action that makes alignment easy to judge. If your channel is mainly ambience, test any clear transient in the audio against a visible change, and inspect longer sections for gradual drift. The point is to observe the symptom under the conditions the channel will actually use.
If managing a computer and a long-running process is itself the fragile part of your setup, StreamNeo can remove the need to leave your own computer running by taking an uploaded video and carrying it as a YouTube live stream. That addresses the operational burden of keeping the broadcast running; you still need to prepare and check the media and confirm the stream’s audio and picture are in sync.
Collect file and FFmpeg details if unresolved
If the problem persists, collect the information that would let someone distinguish source timing from an output or loop issue. Include the complete FFmpeg command with the stream key removed, the output of ffmpeg -version, relevant FFmpeg logs, and ffprobe details for the input’s audio and video streams. Record where in the file the mismatch first appears and whether it changes at the next boundary.
Never publish your stream key. YouTube treats it like a stream password: anyone who has it may be able to send a broadcast to your channel. Remove the key and any other credentials from commands, screenshots and logs before sharing. If there is any doubt that a key has been exposed, check YouTube’s current Live Control Room instructions for replacing it.
When sharing a trace, describe what you actually observed rather than naming a cause. Include whether the same offset was present in a local playback of the source, whether the issue occurred in the outgoing preview, and what changed between a successful and unsuccessful test. A short excerpt of logs is useful only when it includes enough context to show the relevant input and output options; preserve the original privately in case the full trace is needed.
The evidence available here cannot identify the cause for a particular file or FFmpeg build. A useful report narrows the question without pretending to settle it: fixed offset, cumulative drift, boundary jump, or choppy delivery; the version and command; and the stream details. That gives the next troubleshooting step a basis in observation rather than guesswork.
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
How do I keep audio in sync when looping a video?
First establish whether the mismatch is constant, grows through a play-through, or appears at the loop boundary. Inspect the source and test the actual YouTube output before changing timestamps; the pattern alone does not prove a cause.
Why does audio drift out of sync on a 24/7 FFmpeg stream?
A growing mismatch can involve source timestamps, stream timelines, sample rate, frame cadence or processing, but it cannot be diagnosed from the symptom alone. Compare the start and later playback, inspect the file with ffprobe, and retain the FFmpeg version, command and relevant logs.
Does -stream_loop -1 keep audio and video synchronised?
It repeats an input indefinitely, but it does not guarantee that the streams line up throughout playback or across the boundary. Check the source timing and observe several restarts in a representative outgoing test.
Should I use -itsoffset to fix sync?
Use it only when you have measured a roughly constant offset and confirmed which stream leads. It changes input timestamps; it is not a measured remedy for cumulative drift or a loop-boundary jump, and the result must be tested.