Audio and video out of sync in a YouTube RTMP stream is usually fixed by finding where the mismatch begins, rather than applying a standard delay everywhere. Compare the encoder preview, a local recording, YouTube Live Control Room, and public playback before changing source timing.
First decide whether the audio is ahead of the video or behind it, and whether the error stays constant or grows over time. A spoken word, hand clap, or drum hit gives you a repeatable event for checking the lip sync issue on YouTube Live.
Identify which way the sync is wrong
Use a short test with a clear movement and sound. Speak a few words while your face is visible, clap once in frame, or strike a percussion instrument. Avoid judging the timing from a person speaking off camera, because it is harder to identify the exact moment of movement.
Watch for the following:
- Audio ahead of video: you hear the word or clap before the visible movement.
- Audio behind video: the movement happens first and the sound follows.
- Constant offset: the error is similar at the beginning and end of the test.
- Drift: the error becomes larger as the recording continues.
This distinction matters. A constant offset may be addressed with a source timing adjustment. Drift suggests that the two sources are not staying on the same clock, so increasing a fixed delay may only make one part of the recording look correct.
Write down what you see before changing anything. For example, “the clap is visible roughly after the sound in the OBS preview” is more useful than “the stream feels delayed”. You do not need to estimate milliseconds accurately at this stage. You need to identify the direction and the first stage where the mismatch appears.
Also check whether the issue affects every sound source. If a microphone is out of sync with a webcam but a music track matches the video, the microphone or its processing is a more likely place to investigate. If speech, music and system audio are all early or late together, look at the video source, encoder path, or output stage instead.
Do not confuse relative sync with stream latency. Stream latency is the delay between capture and the viewer seeing the stream. It can make the whole broadcast appear later, but it does not by itself show that audio is early or late relative to the picture. YouTube explains the distinction in its stream latency guidance.
Compare the encoder preview with a local recording
Start with the software that is sending the RTMP feed. In OBS, look at the preview while producing the known test event. Then make a short local recording using the same scene, camera, microphone and audio processing used for the live broadcast.
The preview is useful for spotting an obvious problem in the scene, but the local recording is the stronger check because it shows what the encoder actually produced. Review the recording from the beginning and near the end. Check whether the audio and picture are aligned in both places.
Use this comparison to narrow the fault:
| What you observe | Where to investigate first | What it suggests |
|---|---|---|
| The OBS preview and local recording are both out of sync | Camera, microphone, capture device or source timing | The mismatch begins before YouTube receives the stream |
| The preview looks acceptable but the local recording is wrong | Encoder load, processing or recording configuration | The output is changing after the scene is rendered |
| The local recording is healthy but YouTube previews are wrong | Output configuration, network path or YouTube-side processing | The source itself may not be the cause |
| The local recording and YouTube preview are healthy but viewers report a problem | Public playback, player conditions or the outbound connection | Check the actual broadcast and stream health before changing timing |
This is the point to check a suspected capture card audio delay. A capture card may deliver picture and sound through different paths, or the device may apply its own buffering. That does not prove the capture card is faulty. It tells you to compare its direct source behaviour with the encoded recording before replacing hardware.
If the mismatch is already visible in the source or OBS preview, changing YouTube latency mode is unlikely to address the relative timing. If the local recording is clean, avoid changing microphone offsets simply because the public player feels late.
YouTube’s live-stream troubleshooting guidance recommends checking the encoder, local output, CPU load and outbound connection when diagnosing stream problems. Follow that order rather than changing several settings at once. Record each change so you can undo it when the result becomes worse.
For a prerecorded devotional loop, lofi station or local news sequence, include the real programme material in the test. A microphone and webcam test may be irrelevant if the final channel contains only a video file and an audio track. The test should reproduce the path that viewers will actually receive.
Check YouTube Live Control Room preview
Open the stream in YouTube Live Control Room before making it public. The preview gives you another point in the chain between your encoder and the audience. Compare it with the same visible event and sound that you used in the local recording.
If the local recording is out of sync and the Live Control Room preview shows the same relationship, the mismatch is probably being sent from the encoder. Return to the sources and their timing controls rather than adjusting the YouTube event.
If the local file is aligned but the preview is not, check the encoder status and stream health. Confirm that the intended audio source is selected and that the stream is not reporting an encoder problem. Avoid assuming that a preview difference is caused by the latency setting. Lower, normal and higher latency describe how quickly viewers receive the broadcast; they are not established as a universal correction for audio being early or late.
YouTube’s live encoder settings documentation describes the normal requirements for an encoder stream, including RTMP or RTMPS ingestion and supported audio encoding. These settings provide a compatibility baseline. They do not establish one sync offset that works for every camera, microphone, capture device or computer.
Use the Live Control Room preview as evidence, not as the only test. Preview playback can be affected by buffering or monitoring conditions. Keep the local recording available so you can compare the same section of content at the same time.
For a channel that runs overnight, do not begin a long public broadcast while the preview is the only thing you have checked. Let the test run long enough to expose a growing mismatch, especially if the first minute looks fine. A stream can start aligned and gradually separate if the sources do not maintain compatible timing.
Compare public playback with the source
When the preview and local recording look correct, watch the public stream from a separate device or browser. A phone on mobile data can provide a different playback path from the computer that is sending the stream, though it is still not a controlled measurement.
Use the same event again. Note whether the public playback has the same relative alignment as the Live Control Room preview. Do not judge only by how long the public stream takes to appear. That is end-to-end latency, not necessarily an audio-video sync error.
The results normally point to one of three actions:
- The mismatch is present before YouTube: adjust the relevant source or capture path and make a new local recording.
- The mismatch first appears in the YouTube preview: inspect the encoder output, stream health and connection before changing source timing.
- The mismatch appears only in public playback: repeat the test from another playback device and check stream health. If the local file and preview remain aligned, changing a source delay may create a new problem rather than solve the observed one.
Ask another person to watch the public playback if possible, but give them a precise instruction. “Tell me whether the clap sound comes before or after the visible clap” is useful. “Does it look okay” produces a less reliable answer.
For 24/7 channels, you should also inspect an archived section after the test broadcast ends. A devotional video, sleep-music loop or podcast rotation can hide a small offset until speech or a beat returns. If you are planning a prerecorded channel, the workflow in how to stream prerecorded videos live on YouTube from India is relevant to the wider setup, but it does not replace this sync check.
If your current arrangement relies on a home computer staying open all night, removing that variable can make diagnosis simpler. StreamNeo turns an uploaded video into a YouTube-only 24/7 broadcast after you provide the file and stream key, so your own computer is not part of the overnight encoder path. You still need to check the finished source and verify the broadcast output; moving the encoder does not make an unsynchronised file correct.
Check CPU load and outbound connection
A timing problem can be confused with an overloaded encoder. Watch the computer while the test is running. Note whether CPU load rises when the camera, capture card, filters, scaling or recording is active, and whether the encoder reports errors or skipped work.
Do not treat a high CPU reading as proof that it caused the mismatch. It is a clue that should be compared with the moment the error begins. If the local recording becomes irregular at the same time as encoder warnings, reduce the processing path and test again. Remove one filter, lower unnecessary preview work, or use a simpler scene only for diagnosis. Change one thing at a time.
You should also check the outbound connection when the local output is healthy but the YouTube preview or public stream is not. Connection trouble more commonly produces buffering, dropped frames or interruptions than a simple constant offset, but it can still make the remote result appear different from the local recording.
The article on YouTube Live Stream dropped frames: causes and fixes covers connection and encoder symptoms in more detail. Keep that problem separate from relative lip sync: a stream that pauses is not automatically a stream whose audio and video clocks are misaligned.
YouTube’s recommendations include checking the local archive and encoder status, then investigating CPU load and the outbound connection when the local result is healthy. This sequence prevents you from compensating for a network problem by delaying an otherwise correct microphone or camera.
For a simple file loop, CPU demand may be lower than for a live camera scene, but do not assume it is irrelevant. Scaling a high-resolution file, adding multiple browser sources or recording locally can change the encoder workload. If you are preparing a high-resolution broadcast, the 4K 60fps YouTube live stream checklist can help with the wider load and reliability questions.
Adjust the source timing and retest
Only adjust timing after you know where the mismatch begins and which source is late. If the camera picture is late while the microphone sound is early, delaying the rendered video can bring the two closer together. In OBS, the Render Delay filter delays a source’s rendered image and uses milliseconds as its setting. See the OBS Render Delay documentation for the current behaviour and interface details.
Apply the change to the relevant video source, not to the whole scene by habit. Make a small adjustment, produce another local recording, and review the same clap or spoken phrase. If the result is worse, return to the previous value. The right setting depends on the devices and processing in that particular path.
If audio is late and video is early, do not add a video delay simply because it is the control you happen to know. The principle is to bring the late source closer to the early source. Use an audio timing control only when you have verified what it changes in your version of the software, and judge the output recording rather than headphone monitoring.
When a video capture device appears to be delaying the picture, inspect its buffering behaviour. OBS documents that disabling buffering can help with device delay, while buffering may help with stuttering. That makes it a diagnostic option, not a universal instruction. Test both the timing and stability of the result with the actual device in use. The OBS video capture device documentation is the appropriate reference because interface options can change between software versions.
Be cautious with fixed offsets when the error grows over time. A source that is one moment late at the start and much later near the end may need investigation of device timestamps, sample rates, capture clocks or system load. The available guidance does not support one universal correction for every drift pattern, so do not keep increasing an offset until one short section looks right.
After every timing change, repeat all four checks: encoder preview, local recording, Live Control Room preview and public playback. The adjustment is not confirmed because the OBS preview looks better. It is confirmed only when the output that viewers receive remains aligned.
Run a representative test before going live
Use the same camera position, microphone, capture device, scenes, filters and file format planned for the real broadcast. Include several types of movement and sound. For a sermon or devotional programme, test speech and music. For a study or ambience channel, test the point where the loop changes and any narration or notification sound that viewers will hear.
Make the test private or unlisted where appropriate, then preview it in Live Control Room. Keep a local archive and review both an early section and a later section. If the stream is intended to run overnight, a very short test may confirm only the initial alignment and miss drift that develops later.
Keep a simple test record:
- source and scene used
- whether audio led or lagged
- whether the error was constant or grew
- local recording result
- Live Control Room result
- public playback result
- one change made and its result
This record prevents circular troubleshooting. It also helps you restore a known-good configuration if a later change to a camera, audio interface or capture card introduces a new mismatch.
Check the official YouTube guidance again before a major broadcast because its interface and recommended encoder settings can change. Do not assume that changing latency, bitrate or the stream key will correct relative timing unless your test demonstrates that relationship. Compatibility settings and sync settings solve different problems.
If the channel is operated from a home computer, plan for the failure mode as well as the initial sync. A machine that sleeps, updates, loses its connection or overloads overnight can interrupt a correct broadcast. Sync testing should be followed by the separate reliability checks described in how to restart a YouTube 24/7 stream automatically after it disconnects.
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
Why is my audio ahead of the video on YouTube Live?
First compare the encoder preview and a local recording with a known event such as a clap. If the audio is already ahead there, investigate the camera or video capture path and delay the late video source only after confirming the result with another recording.
Will changing YouTube latency fix a lip sync problem?
Not necessarily. YouTube latency describes the delay between capture and playback, while lip sync describes the relationship between sound and picture. Test the encoder output and source timing before changing latency mode.
What should I check when OBS audio and video sync starts correctly but drifts?
A growing error is different from a constant offset. Check capture clocks, device timestamps, sample rates and CPU or encoder warnings, then repeat a representative local recording; do not assume that a larger fixed delay will correct the drift.
Can disabling capture-card buffering fix sync?
It can help with some device-delay cases, but it can also affect stability. Treat buffering as a diagnostic setting, test the same movement and sound after changing it, and keep the result that remains both synchronised and free from new stuttering.