A continuous YouTube stream stays in sync when you first identify where the mismatch begins, then measure whether it is constant or changing before making a small correction. There is no universal audio offset that works for every camera, microphone, encoder and playback path.
Audio/video sync and stream latency are related to the viewer's experience, but they are different problems. Use a controlled test with speech and visible movement, compare the local output with YouTube playback, and verify the result during a longer run before changing your production setup.
Audio/video sync is not stream latency
Audio/video sync is the relative position of sound and picture. If a person claps and the sound arrives after the hands meet, the audio is late relative to the video. If the sound arrives first, the audio is early. This relationship can be measured and corrected with a source or encoder adjustment.
Stream latency is the delay between capture and the moment a viewer sees the stream. YouTube describes it as the delay from camera capture to viewer display. A viewer might see and hear a perfectly aligned picture several seconds after the event happened. That is latency, not necessarily a lip-sync error.
The distinction matters on an always-on channel. A devotional recording may be synchronised internally while a viewer sees the whole programme later than the live source. A local news presenter may appear to speak correctly on the broadcaster's preview but seem delayed when a viewer sends a message, because the message travels through the live delivery path.
YouTube's latency guidance describes normal, low and ultra-low latency as choices with different interaction and buffering trade-offs. YouTube says most viewers on low-latency streams experience less than 10 seconds of latency, and most viewers on ultra-low-latency streams experience less than five seconds. Those are typical viewer-delay descriptions, not acceptable tolerances for audio/video alignment.
Changing from normal to low latency will not automatically repair audio that is 300 milliseconds late in the source. It reduces the amount of read-ahead buffer available to the player, which can make delivery more responsive but can also make buffering more likely. Select latency for the way viewers use the channel, then diagnose sync separately.
Identify what is actually out of sync
Before moving a slider, describe the symptom in four parts:
- Is audio early or late compared with the picture?
- Is the error already present in a local recording or preview?
- Is the error constant, or does it grow during the stream?
- Does it appear for every viewer, or only on one device, browser or network?
Use a repeatable test signal rather than judging a long programme from memory. A useful test includes a visible action with a clear sound: a hand clap, a tap on a table, a spoken word beginning with a strong consonant, or a short tone beside a moving object. For a music or ambience channel, include a section with an obvious visual beat rather than testing only a static image.
Run the same test through each stage. First watch or record the source locally. Then inspect the encoder preview or local recording. Finally, watch the YouTube broadcast from a separate device or browser. Write down what you see at each stage. The purpose is not to calculate YouTube's total delay. It is to find the first point where the sound and picture stop lining up.
A local recording that is already wrong points towards the source chain, audio routing, capture device or encoder. A local recording that is aligned but a YouTube playback that looks wrong requires a different investigation. A mismatch that becomes larger over time is different again from a fixed offset that is present from the first minute.
Do not rely on a single phone connected to the same Wi-Fi as the encoder. Its browser, device audio path and network can add their own delay. Compare a second viewer device if possible, and note whether the apparent problem follows the broadcast or remains on one playback setup.
A simple record of the starting state prevents circular troubleshooting. Note the microphone or audio file, camera or video file, frame rate, audio sample rate, encoder, bitrate, keyframe setting and any sync offset already applied. Change one relevant item at a time and repeat the same test.
Check the source and encoder path
Many apparent YouTube problems begin before the stream reaches YouTube. Check the complete chain from source to encoder:
audio source → audio routing → capture or playback layer → encoder → upload → YouTube playback
For a prerecorded file, confirm that the audio and video are aligned in the file itself. Play the file outside the streaming software and inspect a section with speech or a clear impact. If it is wrong there, a live encoder offset is treating the symptom rather than repairing the media.
For a camera and microphone, check whether they enter through the same device and timing path. A camera capture device may buffer video while an audio interface supplies sound with a different delay. That does not mean a new capture card is the answer. First establish that the capture path is where the error starts. Hardware should be investigated when the evidence points to it, not purchased as a general cure for drift.
Check that the encoder is using a stable, supported configuration for the protocol you selected. YouTube's current encoder settings guidance lists H.264, H.265 and AV1 video for RTMP or RTMPS, AAC or MP3 audio, constant bitrate, and up to 60 frames per second. It recommends a two-second keyframe frequency and says it should not exceed four seconds.
The same guidance recommends 44.1 kHz for stereo audio and 48 kHz for 5.1 audio. It lists 128 Kbps for stereo audio and 384 Kbps for 5.1 as recommended audio bitrates. These are encoder guidance values, not audio-sync corrections. HLS has separate requirements, so do not copy RTMP settings into a different ingestion workflow without checking the relevant documentation.
Audio and video break-up can make a stream look out of sync even when the timestamps are correct. Dropped frames, repeated frames, buffering and disconnects interrupt the visual rhythm while the audio continues, or do the reverse. Check the stream's health messages and the encoder log around the time the problem appears.
YouTube's live documentation includes health signals such as low video bitrate, frame-rate mismatch and no audio stream. Its Live Streams API documentation is useful if your workflow exposes these states programmatically, but you do not need an API to perform the basic check in Live Control Room. Watch the health panel and read its messages rather than assuming that every warning is a sync fault.
If the encoder is running on a computer, check its resource use and whether the selected bitrate is sustainable on the upload connection. OBS explains that dropped frames commonly indicate an unstable connection or a bitrate the connection cannot maintain, and its connection troubleshooting guide discusses bitrate, network equipment and other software in the path. A VPN, security tool, router problem or congested Wi-Fi connection can matter even when a short speed test looks acceptable.
For operators who have moved from a local computer to an always-on workflow, the same principle applies. A cloud-based service can remove the need to leave your own computer running, but it cannot make a poorly aligned source file correct. StreamNeo is useful when the particular pain is keeping an uploaded programme running without your computer switched on, while the media and its sync should still be checked before upload.
Measure and adjust a constant offset
Once you know the mismatch is constant and repeatable, measure its direction before adjusting it. Use the clap or spoken consonant from your test recording and compare the visual event with the beginning of the sound. If the audio arrives after the visual event, audio is late. If the sound begins first, audio is early.
Use the sync controls in the software that owns the relevant timing decision. Depending on the workflow, that may be an audio source offset, a capture-source delay, a media-source setting or an encoder setting. The names and signs differ between applications, so confirm what a positive or negative value does in that application before applying it to a live channel.
Make a small, measured change and repeat the test. Do not change the audio offset, frame rate, sample rate and capture device at the same time. If several variables move together, you will not know which one corrected the problem, and a later restart may bring back a hidden conflict.
A practical test record might say: “At the start, the clap is visibly early and remains so in the local recording. After one small audio adjustment, the clap aligns locally but must still be checked on YouTube.” That is more useful than writing down a supposed standard offset. The correct correction depends on the source, the direction of the error and the delay introduced by the particular capture path.
If the mismatch grows gradually, stop treating it as a simple fixed offset. A constant delay can be corrected once. Drift suggests that timing is changing as the run continues, so repeat a longer controlled test and look for inconsistent source timing, resource warnings, dropped frames or configuration differences. The reviewed platform guidance does not identify one universal cause of gradual drift, so the cause must be established from the setup's evidence.
For a looped file, test across a loop boundary as well as inside one clip. The transition may reveal a file with different properties, a playlist hand-off, a missing audio stream or a source that is being reinitialised. If the first item is aligned and every later item changes position, inspect the playlist or media preparation rather than applying a larger global delay.
When the stream is assembled from several prerecorded videos, stable switching matters as much as the individual files. If that describes your setup, the workflow in how to make OBS switch between prerecorded videos on YouTube Live may help you inspect the hand-off points, but you should still test each source and transition for sync.
Understand how latency affects buffering
After relative sync is correct, choose a latency mode based on the channel's purpose. A study channel, devotional loop or ambience station may not need viewers to respond immediately. A local news or community channel with active live chat may place more value on faster interaction.
Normal latency is intended for non-interactive streams and supports all resolutions and features according to YouTube's guidance. Low latency reduces the delay for most viewers but may increase buffering. Ultra-low latency reduces it further and increases the risk of buffering again; YouTube's guidance also states that low and ultra-low latency do not support 4K.
This creates an important trade-off for a continuous stream. A lower player buffer leaves less room for short interruptions in delivery. If the upload path pauses briefly, viewers may see a spinner or a pause sooner than they would under a more buffered mode. A lower setting can therefore make an existing delivery problem more visible without being the cause of the audio offset.
Do not use latency mode as a lip-sync slider. If the picture and sound are aligned in the local recording but one viewer reports a delay, first compare another device and check buffering. If the same relative mismatch appears in the source and in YouTube playback, use the measured source or encoder correction instead.
For an always-on operation, reliability often matters more than shaving a few seconds from viewer interaction. Make the choice deliberately, based on whether viewers need immediate responses and whether intermittent buffering is acceptable for the programme. Recheck YouTube's current help page when the channel's format or resolution changes.
Verify alignment during a long stream
A short test can confirm the starting offset but cannot prove that a channel will remain aligned overnight. Run a private or unlisted test when the workflow permits, using the same files, sources, encoder settings and connection that will be used for the public broadcast. YouTube recommends testing with audio and motion resembling the actual event, then monitoring stream health and messages during the event.
Test for long enough to reproduce the reported symptom. The required duration depends on how quickly the problem appears, so do not choose a universal test length. If viewers report drift after a particular part of the night, include that duration in the controlled test before changing hardware or moving platforms.
Keep a simple log with these fields:
| Observation | What it helps distinguish |
|---|---|
| Wrong in the source file or local recording | Source media, routing or capture path |
| Aligned locally, wrong immediately on YouTube | Ingest, playback comparison or delivery path |
| Constant offset from the start | A measured source or encoder correction may help |
| Offset grows during the run | Timing, resource, dropped-frame or configuration investigation |
| Buffering and dropped frames begin together | Network stability or sustainable bitrate |
| Only one viewer or device reports the issue | Player, device or local network behaviour |
Record the time when the first visible change occurs. If the broadcast starts aligned at 21:00 and appears late at 02:00, that is more useful evidence than “it drifts overnight”. At the same time, record stream-health warnings, bitrate changes, disconnects, CPU or hardware-encoder warnings, and any source transition near that point.
Watch the actual YouTube playback from a separate device rather than relying only on the encoder preview. Keep the test viewer in the same general playback mode used by the audience, but do not mistake the viewer's total delay for a relative sync measurement. The clap should still line up when it is eventually displayed.
If your channel plays a fixed video repeatedly, place a short, recognisable sync marker in a private test version rather than altering the public programme. Compare the marker at the beginning, near the middle and after a loop. Remove the marker from the public file once the test is complete.
For operators who want to avoid a home computer becoming the point of failure, it may help to read 24/7 streaming without a PC: what actually runs the stream. The operational lesson remains the same whichever arrangement you use: test the exact path and monitor it after the change.
When to investigate the player or delivery path
If the local recording is aligned, the encoder reports a healthy stream, and most viewers see alignment, investigate the individual playback report before changing the broadcast. Ask which device and browser were used, whether the viewer was on Wi-Fi or mobile data, whether buffering occurred, and whether another device shows the same behaviour.
A player may pause, recover from a network interruption or change its buffer while the broadcast continues normally. That can make a viewer feel that audio and video have separated even though the encoded stream is aligned. Compare a second playback and look for a repeatable pattern before applying an offset that would make the main audience worse.
If many viewers report the same relative mismatch while the local recording is correct, preserve evidence before restarting. Save the time of the symptom, the broadcast URL, health messages and encoder settings. Check whether the problem began after a source change, a resolution change, a reconnect or a playlist transition.
A stream-health warning does not by itself prove the cause of a sync error, but it narrows the investigation. Low bitrate, frame-rate mismatch, no audio stream and ingestion starvation deserve attention before fine-tuning milliseconds. A delivery problem can make timing appear unstable, and an audio configuration problem can exist even when the network is healthy.
Do not buy a USB HDMI capture card, audio interface or dedicated sync device until a test shows that the corresponding segment is responsible. Hardware can be appropriate when a capture path demonstrably adds an inconsistent or measured delay, but it is not a general solution for clock drift, routing mistakes, encoder overload or player buffering.
If the channel is built from a playlist, also check what happens when an item fails or has a different format. The guidance in how to keep a YouTube playlist streaming when one video fails is relevant to continuity, while sync still needs its own marker-based verification.
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
Does lower YouTube latency fix audio delay?
No. Latency is the time between capture and viewer display, while sync is the relative timing between audio and video. Lower latency reduces player read-ahead and can increase buffering, so adjust it for interaction needs rather than using it as a lip-sync correction.
Should I add a standard millisecond audio offset?
No universal value is reliable across cameras, microphones, capture devices, files and encoders. First establish whether audio is early or late and whether the error is constant. Then make a small measured adjustment in the relevant software and repeat the same test.
Why is the stream aligned at first but drifting later?
A growing mismatch is not the same as a fixed offset. Run a longer controlled test and record when the change begins, then inspect source timing, configuration differences, resource warnings, dropped frames and playlist transitions. Do not replace hardware until the evidence identifies the capture path as the cause.
What should I check when only one viewer reports the problem?
Compare the broadcast on another device or browser and ask whether buffering occurred. If the local recording and other viewers are aligned, investigate the first viewer's player, device and network before changing the stream's global audio timing.