If audio and video in an FFmpeg YouTube gaming stream start together but drift apart during a long VOD loop, first establish how the error changes over time and whether it resets or jumps at a loop boundary. Those patterns point to different investigations; without the command, build, source media and timing evidence, there is no responsible one-flag fix to prescribe.
Measure the offset at the start, at later points and immediately before and after a replay. Then compare the local source, the outgoing stream and YouTube’s live preview or VOD. The aim is to find where the timelines diverge, not to guess which part is at fault.
Does the error grow, stay fixed, or jump at the loop?
Describe the symptom before editing the command. A fixed offset means the sound is already early or late at the beginning and stays roughly that distance away. Gradual drift means the gap grows or shrinks as playback continues. A loop-boundary jump means sync is fairly steady during a pass, then changes abruptly when the video restarts. These are useful distinctions, not diagnoses on their own.
Write down the direction as well as the shape. Is a gunshot heard before its muzzle flash, or after it? Does that difference widen as the stream runs? Does it return to its earlier value at the start of the next pass? A viewer’s impression that audio is “slowly getting out of sync” is worth investigating, but repeatable observations are much easier to compare with timestamps and logs.
Take observations at several elapsed times, including one close to the first loop transition. Record the approximate audio-versus-picture offset in ordinary terms, such as “the sound is ahead of the action”, and note the playback point or wall-clock time. Do not invent a drift rate from a brief impression. A few carefully chosen observations can distinguish a constant delay from a growing error or a repeatable discontinuity.
| What you observe | First question to investigate | What it does not prove |
|---|---|---|
| Similar offset from the start onwards | Was audio already displaced in the input or introduced during processing? | It does not show that an input offset flag is the right correction. |
| Error grows during one uninterrupted pass | Do audio and video timestamps progress as expected relative to one another? | It does not identify a single clock, filter or encoder as the cause. |
| Sync changes at a loop boundary | Do the repeated inputs have compatible durations and continuous timestamps? | It does not prove the loop mechanism alone is responsible. |
| Local file looks aligned, but a YouTube view does not | Does the difference occur in the live preview, only in the VOD, or at particular playback qualities? | It does not by itself prove YouTube transcoding caused the change. |
More than one pattern can be present. A file may begin with a small offset and then drift, or sync may change at a loop while also moving gradually within each pass. Keep those observations separate rather than forcing the problem into one category.
Compare audio and video in the input file
Before investigating YouTube, check whether the supplied file itself stays in sync. Play the beginning, a middle section, a late section and the material around the end where the loop occurs. Choose moments where a sound has a clear visual counterpart: a menu selection, impact, spoken line or other event whose timing you can judge. Background music over a static image is a poor test of lip or event synchronisation.
If you can, make a local test recording from the same FFmpeg command or render a short local output using the same inputs and relevant filters. Compare the same identifiable event in the original media and the output. If both are aligned locally but the YouTube live preview differs, the evidence shifts towards the path after local processing; it still does not establish which delivery stage is responsible. If the local output already drifts, investigate the source and command before blaming YouTube.
Check the media’s streams and metadata, not just its filename or container extension. Note whether there is one audio stream or several, the audio sample rate and channel layout, video frame rate, durations, codec details, and any reported start-time difference. A container can hold streams whose timestamps or durations do not line up neatly. Metadata is evidence about the file’s structure, not proof that a viewer will see a particular symptom.
When the gaming VOD has been edited, joined, captured from a variable-frame-rate source or exported with separate audio, note that history. Do not assume any of those details are necessarily the cause. They are clues that make it more important to compare the actual stream timelines than to apply a generic delay or synchronisation setting.
For a repeatable test, use an unchanging segment from the same file and compare the start and a later event in that segment. If there is a local recording, retain it rather than relying only on memory of a live preview. A troubleshooting process that includes a comparison of looped prerecorded video may also benefit from the practical context in how YouTube Live Control Room and looping services differ; here, the important point is to keep the media and timing evidence specific to your stream.
Inspect timestamp progress, not just the displayed picture
A file can look plausible in a media player while its timestamps still deserve attention. FFplay’s -stats output can report audio/video synchronisation drift during playback. Use it as a diagnostic observation: note the reported drift at the start and later points, and compare those readings with what you see and hear. FFplay also has a master clock for synchronisation; changing clock selection is principally a debugging aid, not a general command-line cure.
FFmpeg documents -debug_ts for examining timestamp information. Its output is explicitly a debugging aid and may differ between versions, so save the FFmpeg version and the relevant log along with the media details. Look for how audio and video presentation times progress across the same interval. A single line copied from a log without context rarely tells you whether the timeline is wrong; the useful evidence is the progression before, during and after the observed sync change.
Record the stream time bases and the timestamps at matching points where practical. A time base describes the units used to represent timestamps; it does not mean every stream must display the same raw numbers. Compare the represented timing after accounting for those units, and avoid treating two different timestamp scales as directly interchangeable. If you do not know how to interpret the fields, preserve the full output for someone who can rather than changing flags based on a partial excerpt.
Keep a small observation log: elapsed playback time, event or loop position, perceived direction and size of the offset, relevant FFplay statistic, and any timestamp or health message at that moment. Repeat the comparison after a loop. This helps answer whether the drift is continuous, whether it resets, and whether an apparent YouTube-side change coincides with an ingestion interruption.
Timestamp controls should follow the evidence. FFmpeg documents options such as -itsoffset, which adds an offset to input timestamps, and -itsscale, which rescales them. An offset may be relevant to a stable displacement; it does not, by itself, demonstrate how to fix a cumulative error. Rescaling timestamps or altering audio timing without showing which timeline is advancing incorrectly risks hiding the symptom for one segment and making another worse.
Option order is part of the evidence. FFmpeg command-line options often apply to the next input or output, so the same option text in a different position may not describe the same operation. Preserve the complete command in its original order, with secrets removed, before asking for a change. The FFmpeg command-line documentation explains option scope and timestamp-related controls; consult the documentation that matches the installed build when interpreting a command.
Check what happens at the loop transition
If sync jumps at the point where the file repeats, inspect the end of one pass and the start of the next as a pair. Compare the last audible event and last visible event before the restart with the first corresponding events after it. Note whether the change happens on every loop, only after a long run, or inconsistently. A transition that repeats the same jump directs attention to the loop’s timing and input handling, but it is still a clue rather than proof of a sole cause.
Compare audio and video durations and their final timestamps. If one stream ends earlier, or the next pass begins on a different effective timeline, the boundary may expose a discontinuity that was not obvious mid-file. Check whether the looping method restarts both streams together, how it handles the end of each input, and whether the command resets or continues timestamps. These questions require the actual command and logs; the word “loop” alone does not reveal the mechanism.
Look closely at a recording around the transition. A black frame, repeated frame, pause in audio, abrupt audio restart or small gap can help identify what changed. Do not treat a visual pause as proof that the audio timestamps are at fault, or an audio click as proof that the video clock is correct. Both streams and the way they are combined need to be considered.
If the loop is created by concatenating files rather than replaying a single file, list each segment’s audio and video durations, stream layout and start times. A transition between independently prepared clips can behave differently from repeating a single input. That distinction matters when you share the command for review, and it is a good reason to keep a copy of the exact media and playlist used during the test.
A useful comparison is one complete pass followed by the next, using the same event at corresponding positions. If sync is stable within each pass but changes by a similar amount at each restart, prioritise boundary handling in the investigation. If it continues moving even away from the boundary, return to the per-stream timestamp progression. Neither finding supplies a fix by itself; it tells you which evidence to inspect next.
Review YouTube encoder and health feedback
Once you know whether the local output is aligned, compare it with what YouTube presents. Check the live preview during the event, then compare the same identifiable segment in the VOD. If available, review the local recording and compare the VOD at more than one playback quality. Note whether the problem is already present in the preview, appears only in the replay, or seems different at different renditions. This can help locate where the symptom appears; it does not prove a particular YouTube transcoding behaviour caused it.
Review Live Control Room health messages and their timestamps around the moment the sync problem begins. YouTube’s health documentation covers configuration and ingestion conditions such as unsupported audio codec, audio bitrate or sample-rate messages, keyframe frequency and insufficient video ingestion. A warning is useful context, especially if it coincides with a visible interruption. It does not independently prove the source timestamps are correct or identify the cause of cumulative A/V drift.
YouTube’s encoder guidance recommends testing with audio and video movement similar to the real stream and monitoring stream health. That is practical for a gaming channel: a test should include the kind of game motion and sound that viewers will see, rather than a static slate. The same guidance describes platform settings, including recommended audio formats and sample rates; check the current page for the stream type you are configuring rather than treating a setting recommendation as a timing repair.
A healthy-looking preview and an absence of warnings are not a certificate that every source timestamp is sound. Conversely, a health message may point to an ingestion or configuration problem without explaining why audio and video timing changes. Keep delivery evidence alongside local timing evidence. The YouTube encoder settings and testing guidance and its Live health configuration messages are the primary references for current platform feedback.
If the live stream is aligned but a VOD is not, capture the affected segment, quality level and playback point, and compare those against the live preview and local recording. If the live preview also drifts, prioritise timestamps and the outgoing command. In either case, do not infer the cause merely from where you first noticed the mismatch.
Collect the command, build and media details
A case-specific correction needs enough information for another person to reproduce the timing behaviour. Share the complete FFmpeg command in order, but remove the YouTube stream key and any other credentials. Keep input, filter, mapping and output options visible. If a script creates the command, include the generated command as well as the relevant script logic; a shortened excerpt can omit the option placement that explains what FFmpeg actually applies.
Include the FFmpeg version and configuration output, the operating system or environment where it runs, and the source media’s stream metadata. Say how the video is looped, whether audio is looped in the same way, whether the input is one file or a sequence, and whether any filters or separate audio tracks are involved. Do not replace those details with a guess such as “standard FFmpeg settings”.
Add a timeline of observations: when the stream began, when the mismatch was first noticed, offset direction at the start and later checkpoints, what happens at each loop, and whether the same segment differs in a local recording, live preview or VOD. Attach the relevant FFplay statistics, timestamp-debug excerpts and health messages with timestamps. Preserve enough context around a log line to show what happened immediately before and after it.
That packet lets someone distinguish a stable initial offset from accumulating drift and from a loop discontinuity. It also makes it possible to ask whether the audio and video timelines, the loop transition, or the path after local processing deserves closer scrutiny. Until those details are available, avoid applying -async, -itsoffset, -vsync, a timestamp scale or a resampling change as a presumed solution. The correct next step is to collect evidence, not to make a flag fit a symptom description.
If your aim is to keep a prerecorded channel running while your own computer is off, StreamNeo removes the separate burden of leaving your machine running for the broadcast; it does not replace the timing checks needed to confirm that the source file is in sync. For the underlying channel workflow, see how a 24/7 language-learning stream can run without a PC or how to keep a YouTube stream running when a video file ends.
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 add -itsoffset to fix audio that drifts over time?
Not without evidence that the problem is a fixed initial offset. -itsoffset changes input timestamps by an offset; a constant shift does not, on its own, correct an error that grows during playback. Compare timing at multiple points and inspect the command and timestamp logs first.
Does a YouTube health warning mean YouTube caused the sync issue?
No. A warning can identify an encoder configuration or ingestion condition, and its timestamp may help correlate it with an interruption. It does not establish that source timestamps are correct or prove the warning caused the audio/video mismatch.
What should I send when asking someone to diagnose the command?
Provide the full command with the stream key removed, FFmpeg version and configuration, input media metadata, and details of how the loop is made. Include sync observations at multiple elapsed times and around the loop boundary, plus local or YouTube comparisons and relevant logs or health messages.
What if the stream is aligned live but not in the VOD?
Compare the same segment in the live preview, local recording and VOD, noting playback quality and the point where sync differs. This narrows down where the symptom appears, but does not prove a specific YouTube processing stage caused it. Keep the evidence before changing the FFmpeg timing settings.