Start by comparing the YouTube replay with the local archive recorded by your encoder. If both have the same sync fault, investigate the capture and encoding path; if the archive is clean, compare replay playback qualities and gather evidence before deciding what to report.
There is no universal switch that fixes every 4K 60fps replay. A replay-only symptom is not, by itself, proof that YouTube transcoding caused it. Work through the tests below in order, and keep the original archive and logs until you understand where the fault first appears.
Compare the replay with the local archive
Find a recognisable event in the stream: a spoken word followed by a visible mouth movement, a drum hit matched to a hand strike, or a title animation timed to a sound cue. Compare that same moment in the encoder’s local recording and the replay. YouTube’s live-stream troubleshooting guidance specifically recommends looking for audio or video problems in the local archive.
Check more than one point. Note the offset near the beginning, around the middle, and near the end of the affected section. If a spoken syllable is consistently late by about the same amount throughout, that suggests a fixed offset. If the difference grows as the stream continues, record that too: gradual drift and a steady offset are different symptoms and can point to different parts of the chain.
Do not rely on memory or judge the entire replay at once. Use a written note with the approximate replay time and what you see and hear. If possible, compare the files on the same device, in the same media player, and at the same timestamp. Different players, buffering and playback conditions can cloud the comparison.
| What you observe | What it helps you test next |
|---|---|
| Local archive and replay have a similar fault | Check capture, routing, device timing and encoding performance. |
| Archive appears clean; replay appears faulty | Compare replay qualities, devices and viewers before escalating. |
| Offset is similar at each sample point | Record it as a steady offset and note the affected events. |
| Offset grows across the stream | Record the sample times and investigate timing or performance over time. |
This table does not identify a cause on its own. It gives you a useful first fork and a way to describe the symptom precisely. Preserve the original archive rather than replacing it with an edited copy; otherwise you may erase evidence of where the fault started.
If both are out of sync, trace capture and source routing
When the local archive has the same fault, begin at the source. Check whether the audio was already late or early before it entered the streaming application. If you have a source file or a separate audio recording, compare a short section against the archive. A fault present before encoding is not something a YouTube playback setting can repair.
Next, follow the signal path in your encoder. Identify where each sound enters: a microphone, desktop audio, an interface, a media source, or a mixer. In OBS, check whether the same device is captured once globally and again as a scene source. OBS warns that capturing a device in both ways can create echo. Echo is not the same as a timing diagnosis, but duplicated routing can make it harder to identify which audio path you are hearing.
Disable one duplicate route at a time for a controlled test, then record a short sample and check it. Avoid changing several audio sources, delay values and video settings together. If the result improves, you need to know which change mattered; if it worsens, you should be able to restore the previous setup.
Check source timing after a scene change as well. A microphone or music source may enter a scene differently from the background video, or a media source may restart while the audio continues. Test the transition that appears in the archive, not only a quiet section where both sources run continuously. For a recurring file-loop issue, the checklist in this OBS media-source troubleshooting guide can help separate playback behaviour from sync symptoms.
If your stream is a prerecorded loop, compare the source file’s audio and video before loading it into OBS. The notes in this guide to video formats for looping nature footage are useful when you need to rule out a source-file or media-playback problem. They do not establish that a particular format causes desync; the practical test is to inspect the same moments in the source and the recorded archive.
Check audio-device timing and encoding performance
Audio devices and the encoder’s timing choices can affect a stream, but no single setting is a general cure. In OBS on Windows, the audio capture option “Use Device Timestamps” is documented as attempting to prevent desync. Treat it as a test: note its current state, change only that option, and compare a new recording made under otherwise similar conditions. The OBS Audio Sources documentation describes the option and its scope; it does not promise that enabling it will fix every fault.
Check the selected sample rate as well. Google’s Live Streaming API health documentation identifies audio sample-rate issues and lists 44.1 kHz and 48 kHz as recommended rates. A warning is a reason to inspect the setting, not proof that it caused your particular sync problem. Make a note of the encoder’s audio rate and the source device’s rate, and avoid changing them in the middle of diagnosis without recording the previous configuration.
A 4K 60fps output asks more of the system than a lower frame-rate or resolution target. OBS explains that rendering and encoding load affect performance and suggests reducing resolution or frame rate when the system cannot keep up. If the archive has missing or uneven frames, or OBS logs show rendering or encoding strain around the affected time, try a short 30fps test. That changes the output target, so it can help test whether load is involved but cannot prove the original cause by itself. See OBS’s encoding performance guidance before changing settings.
Also check that your ingest settings match YouTube’s current recommendations. YouTube Help lists, for 2160p at 60fps, a recommended 35 Mbps and minimum 10 Mbps for AV1 or H.265; for H.264 it lists a recommended 50 Mbps and minimum 14 Mbps, as listed on YouTube Help’s site in October 2026. Those are stream-ingest bitrate figures, not a sync tolerance or a repair guarantee. YouTube also recommends constant bitrate encoding and a two-second keyframe interval, with keyframes not exceeding four seconds. Its encoder settings page lists supported settings and recommends testing with representative movement and audio.
Use these figures to check whether your encoder configuration is within the stated guidance, not to infer a cause from a number alone. If you lower resolution or frame rate for a test, make a note of the setting and compare a new local archive as well as the replay. If the fault disappears only after a change, repeat the test before treating that change as a reliable fix.
Review stream-health warnings
Open the Live Control Room’s stream-health information for the broadcast and read the encoder log for the same period. Look for a warning that matches the time of the sync symptom. YouTube’s Live Streaming API documentation describes health issues involving audio settings, bitrate, frame rate, GOP or keyframe configuration, and insufficient video ingestion. Those checks can identify configuration or delivery concerns; they do not state that every listed warning causes audio and video to drift.
Keep the timestamps together. For example, record “replay around 01:12:30; local archive also late; encoder warning at approximately the same time” rather than writing only “audio out of sync”. If there is no corresponding warning, record that too. A clean health report does not prove the encoder output was flawless, but it is part of the evidence.
YouTube’s troubleshooting advice also distinguishes a problem reported by one viewer from one reported by viewers on different connections. Ask one or two viewers to test, if practical, and note their device, browser or app, playback quality, and whether the fault appears at the same replay time. A single-device symptom may be local to that viewer’s computer or connection; reports across different viewers call for checking the stream and playback path more broadly.
For a channel that runs continuously, a recovery procedure can matter after a separate encoder interruption, but a restart does not explain or repair a sync fault already recorded in the archive. Keep those problems distinct. If you need to review restart behaviour separately, see how to keep a prerecorded stream running after a reboot.
If only the replay is affected, compare playback qualities
If the local archive is clean, replay the same event at more than one available playback quality. Note the quality label, device, browser or app, and whether the audio-video relationship changes. Where possible, repeat on another device or connection. A fault that appears at one quality on one device is different evidence from a fault reproduced at multiple qualities by several viewers.
YouTube automatically creates multiple output formats from a live stream. That means quality-specific playback is worth testing, but the existence of transcoding does not prove that it caused the desynchronisation. Do not tell yourself that YouTube will reprocess or correct the replay unless YouTube gives you that guidance for your specific case. The controlled comparisons matter more than guessing at what happened behind the playback path.
When testing, use the same replay moment rather than comparing a live broadcast with an archived segment at a different point. Wait for playback to settle, then note what happens at the event you chose earlier. If the issue changes after switching quality, capture both observations. If it happens only on one device, ask whether that viewer can reproduce it in a second browser or app; do not ask them to change many settings at once.
A clean archive and a replay fault that several viewers reproduce is a useful report, not a diagnosis. If your stream comes from a fixed playlist, retain the source and the encoder’s copy separately so you can show which file you checked. A replay-only symptom may be hard to reproduce later, so write down the exact time and conditions while the evidence is available.
Collect evidence before contacting YouTube
For a persistent replay-only fault, assemble a small, factual report. Include the replay URL privately when contacting support, the local archive, the timestamps and example events, and whether the offset stays steady or grows. Add the playback quality, device, browser or app, and whether other viewers on different connections reproduced it.
Include the encoder name and relevant output settings: resolution, frame rate, codec, bitrate mode and value, keyframe interval, audio codec and sample rate. Attach or retain the Live Control Room health report and OBS logs, with timestamps around the affected segment. If you tried a controlled change, say what you changed and whether the local archive and replay changed. This is more useful than a long list of unrelated settings you altered at once.
Keep the language observational. “At 00:18:40, the local archive is in sync; at the same replay time, two viewers hear the vocal late at 2160p and 1080p” is specific. “YouTube transcoding broke the audio” is a conclusion the evidence may not support. YouTube Help advises reporting persistent stream problems; use its current support route and follow any request for additional information.
Do not delete, replace or re-upload the replay as a first diagnostic step. The official guidance reviewed here does not establish that waiting, deleting, or re-uploading is a general repair. Keep copies of the original files and logs while you investigate. If you operate a channel from a computer that must remain on, StreamNeo removes that specific always-on-computer burden by running an uploaded video as a YouTube live stream, but it does not diagnose or correct a sync fault already present in a file or replay.
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 a 4K 60fps replay being out of sync mean YouTube transcoding caused it?
No. YouTube makes multiple output formats from a live stream, so comparing playback qualities can provide evidence, but that fact alone does not identify the cause. First compare the replay with the local archive and record what changes across qualities and devices.
Should I change the audio delay setting in OBS?
Only as a controlled test when you have established what is out of sync and where. Record the current setting, change one thing, make a new archive, and compare the same kind of event. An audio delay can mask a steady offset but is not a universal answer to growing drift or a replay-only problem.
What bitrate should I use for 4K 60fps?
YouTube Help lists different 2160p60 recommendations by codec: 35 Mbps recommended for AV1 or H.265, and 50 Mbps for H.264, with lower minimums. These are ingest recommendations, not sync guarantees; check the current official settings page and your stream-health report.
What should I send YouTube if the archive is clean?
Send the replay URL through the appropriate support route, plus the local archive, sample timestamps, playback quality and device details, encoder settings, and health or OBS logs. State whether other viewers reproduced it and describe what you observed without assigning a cause you have not confirmed.