A 24/7 YouTube radio stream can have a constant audio offset, a gap that grows over time, or a playback problem that appears only on some devices. These are different symptoms, so measure when and where the mismatch appears before changing an encoder setting.
Compare the stream near its start and later in the broadcast, then compare the local encoded output with YouTube playback. Logs and timestamped health messages can help locate the first point where the symptom appears; without those details, there is no responsible universal OBS setting or FFmpeg flag to prescribe.
Audio offset or growing drift?
Start by describing the pattern rather than naming a cause. A fixed offset means the audio appears to lead or lag by roughly the same amount at the beginning and later. Growing drift means the gap changes progressively as the stream continues. An intermittent problem, such as a brief audio interruption or a sudden jump, is different again.
This distinction matters because a one-time delay adjustment can move audio relative to video, but it cannot correct a continuing rate mismatch. If the audio is already behind at the start and remains similarly behind later, investigate where that fixed delay enters the chain. If it starts close to sync and moves further out, look instead at ongoing timing, timestamps, resampling or the relationship between source clocks. Those are investigation paths, not diagnoses: the actual cause depends on the equipment, files and software in your stream.
For a radio stream with a mostly static image, there may be no obvious lip movement to judge. Choose a repeatable reference instead. It might be a visible cue aligned with a musical transition, a scheduled image change tied to a spoken announcement, or a known audio event that you can compare between an encoder preview and the delivered playback. If your visuals carry no timing information at all, use stream statistics and local playback tools rather than treating a still image as proof that audio is synced.
Also note whether the audio leads or lags. “Out of sync” is not enough for a useful test record. Write down which way the error goes, where you observed it and roughly how it changed. This simple description prevents a later adjustment from correcting the wrong direction.
Measure sync at multiple points
A single listen tells you that something may be wrong; it does not tell you whether the error is fixed or accumulating. Measure near a known start point and at later points in the same run. If you can observe the same event each time, note whether its audio and visual timing relationship changes. Keep the observation method consistent so that you are comparing like with like.
FFplay can be useful when you are checking a local stream or recording. Its documented -stats output includes stream position and audio/video synchronisation drift, alongside other playback information. See the FFplay documentation for the version you use. Record the reported drift at more than one point; treat it as diagnostic evidence, not as a control that automatically repairs the stream.
A simple log might include the clock time, stream position, whether audio leads or lags, approximate observed gap, which player you used and any relevant encoder counters. For example, “start: audio slightly late in local preview; later check: still slightly late” describes a different pattern from “start: close; later check: audio increasingly late.” Avoid implying precision your tools cannot support. A rough, repeatable observation is more useful than a precise-looking number produced by an inconsistent method.
Make observations over a representative stretch of operation. A short test may show that a configuration starts correctly while missing a gradual change that becomes visible only later. You do not need to assume that drift must happen on a particular schedule; choose later checkpoints that make sense for your stream and note the elapsed time between them.
Keep the current configuration and logs before testing changes. If you alter the source, encoding, audio format and connection at once, you will not know which change affected the result. This is especially important for an always-on channel: the goal is not only to make one playback look better, but to learn whether the behaviour returns over a normal operating period.
Compare local output with YouTube playback
Listen to or watch the output produced by your encoder, then compare it with the actual YouTube stream. The local preview may be an OBS preview, a local encoded output, or a recording of the outgoing stream, depending on your setup. Be clear about which one you are checking; a preview before encoding is not identical to the encoded signal sent to YouTube.
If the same growing mismatch is already present in local encoded output, focus first on the source and encoder path. That path may include a media player, audio interface, capture device, mixer, resampling step or multiple sources with separate clocks. The symptom narrows where to investigate, but it does not by itself prove which part is responsible.
If local output appears consistent but YouTube playback does not, do not immediately alter the source. Check the outgoing stream’s health messages and compare playback on another device or player. Live playback can be affected by buffering and player behaviour, so a difference between two viewers is evidence to investigate, not proof that YouTube or your source is at fault. If the issue only appears on one device, record that distinction before changing the encoder.
For a cloud-based prerecorded workflow, it may help to understand which output you are actually monitoring and where the stream is produced. The guide to using a cloud encoder for a prerecorded YouTube live stream explains that kind of workflow. The point here is not to switch services as a sync fix, but to identify which part of your own chain generated the output you are comparing.
When comparing local and delivered versions, make the comparison at corresponding stream content, not merely at the same wall-clock time. Live playback may be delayed relative to the encoder, so find the same audio event or visual cue in each version. Note both the apparent sync within each version and any overall delivery delay separately: a stream arriving later is not automatically audio drift.
Review Live Control Room health messages
YouTube’s Live Control Room reports errors detected in the stream being sent to YouTube. Its live streaming error guidance explains the messages and recommendations. Review the messages alongside your observations, noting their timestamps and severity, and whether they began near the point when the sync pattern changed.
A message that coincides with a change is a useful lead. It is not enough on its own to establish that the reported condition caused the drift. Likewise, no visible health error does not prove that every upstream source clock, timestamp or local playback path is correct. Use the health panel as one part of the evidence, together with local output and encoder logs.
The same YouTube guidance describes stream-format requirements and recommendations, including H.264 video, AAC or MP3 audio, a single audio stream, mono or stereo audio, and a 44.1 kHz audio sample rate. It also advises keyframes every two seconds, with an interval no longer than four seconds, and lists a recommended audio stream bitrate. Check the current guidance for the selected format and resolution before changing these values. They concern ingestion and configuration; matching them does not, by itself, diagnose or guarantee a cure for a separate timing mismatch.
If a health message identifies an ingestion issue, resolve and verify that issue before drawing conclusions from a later sync test. Keep the before-and-after observations. This can help you separate an ingestion change from an unrelated change in local timing, and gives you a record to share if you need help from the encoder or platform support team.
Check the source and encoder chain
Write down the route from source material to YouTube: the media files or live inputs, the software that plays them, any mixing or capture step, the encoder, and the destination. Include whether audio and video come from the same file or from independent devices. A chain with separate clocks can behave differently from one file containing both tracks, but the chain description alone still does not identify a fault.
If you use OBS, inspect its logs and dropped-frame counter rather than inferring a cause from the appearance of the stream. OBS explains that an increasing dropped-frame count with a yellow or red connection indicator means the connection is unstable or cannot keep up with the configured bitrate; OBS drops video frames to avoid buffering. Its dropped-frames troubleshooting guidance describes that evidence. It is relevant to the outgoing video path, but it does not show that network trouble explains every case of progressive audio drift.
For FFmpeg, review the command, input details, output timestamps and logs as a whole. Do not paste a filter or flag from a forum post simply because its name sounds related to sync. FFmpeg documents audio filters such as aresample, but the behaviour and available options depend on the installed version and the way the rest of the chain is configured. Read the FFmpeg filter documentation for that version and test any proposed filter in a controlled output before using it in an always-on stream.
Check whether the original media itself is already out of sync. Play the source file locally and, if practical, inspect a representative segment near its beginning and later in the file. If the file is correct on its own but the encoded local output is not, investigate the steps introduced after the source. If the file already has a fixed or growing mismatch, changing live encoder timing may mask one part while leaving the underlying media issue in place.
For playlists, transitions and repeated content, note whether the symptom resets at a file boundary or continues across it. A repeatable jump at each transition points you towards a different test than a gradual change that continues through a single file. If your stream changes clips automatically, the guide to switching videos automatically in a 24/7 stream can help you map the playback sequence you need to include in your test.
Make one measured adjustment at a time
Choose an adjustment only after the measurements narrow the relevant part of the chain. A roughly constant offset may justify a measured delay change in the component where that delay is introduced. A changing gap calls for investigation of continuing timing and clock behaviour, timestamp continuity and resampling, rather than assuming that a fixed delay will address it. If the symptom occurs only in delivered playback, first investigate that path and its health messages rather than changing a source that looks correct locally.
Before making a change, save the configuration and note the current start and later observations. Change one relevant item, then repeat the same comparison method over a representative stretch. If the result improves, worsens or does not change, record that result before considering another adjustment. Where a configuration change affects both audio and video, note that too; a change can alter one part of the presentation while introducing a different problem elsewhere.
Do not treat a generic offset value, resampling flag or recommended ingest format as a universal correction. You need evidence about the particular source, encoder and playback path before deciding whether that kind of adjustment fits. If you cannot establish where the error first appears, gather more observations or seek help from someone who can inspect the relevant logs and chain details. Avoid running an untested command on the only active broadcast.
A short test is not enough to establish that the trend has stopped. Keep checking the actual YouTube playback and local output at the same kinds of checkpoints you used to identify the original behaviour. Include a normal file transition or other routine event if that is where the symptom appeared. If you operate the channel from a local computer and are considering a different way to keep a prerecorded stream running, the guide to restarting a YouTube live stream after a disconnect covers continuity after a drop; restart behaviour and audio sync are separate problems, so do not treat one as proof that the other is fixed.
Use the results to decide whether the change is worth keeping. If the same drift returns, restore the saved configuration if appropriate and revisit the evidence rather than stacking adjustments. A stable result over the relevant operating period is more meaningful than one apparently corrected moment, though it still does not establish what will happen under every future source or operating condition.
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 can I tell a fixed offset from audio drift?
Compare the direction and approximate size of the gap at a known start point and at later points. A similar gap suggests a fixed offset; a gap that changes suggests drift over time. Use the same reference event and playback method wherever possible.
Will adding an OBS sync offset fix audio drift?
Not necessarily. A constant offset may be suitable when measurements show a stable delay in the relevant part of your chain, but a fixed adjustment does not establish or correct an accumulating timing mismatch. Check local output, logs and YouTube playback before changing it.
Is there one FFmpeg flag that fixes livestream audio sync?
No single flag can be recommended without details of the source, encoder chain and measurements. FFplay statistics and FFmpeg’s documentation can support diagnosis, but a filter or timestamp change needs to match the observed problem and should be tested before it reaches the live output.
What if local playback is in sync but YouTube is not?
Compare the same stream event in both places and check Live Control Room health messages around the time the symptom appears. Try another playback device or player and record whether the mismatch is consistent. That evidence helps distinguish the delivered playback path from a problem already present in the encoder output.