If OBS reconnects to YouTube but viewers hear audio with no picture, the connection returning does not prove that video resumed. Compare OBS preview, a local recording from the affected period and YouTube Live Control Room to locate where video disappears before changing settings.
Use the evidence to choose the next step: a missing picture in OBS points towards a scene, source or encoder issue; video in OBS but not in YouTube points towards the outgoing stream or ingest. The same symptom can have different causes, so there is no single reconnect reset that is a verified fix for every case.
Confirm that the symptom is audio without video
First establish what is actually missing. Ask a viewer to describe what they see, or check the live player from a separate device or browser. A frozen image, a black frame, a slate or a delayed picture is not quite the same as no video at all, and the distinction may help when you inspect the preview and error messages.
Check whether YouTube is still live and whether its player is receiving sound. Audio meters moving in OBS, or sound heard in the player, confirm only that audio is present at those points. They do not prove that a video stream is being encoded or delivered. Video needs its own check.
Note when the picture disappeared and when OBS reported reconnecting. Preserve the OBS log for that session and, if one exists, the local recording that covers the outage. Avoid changing several settings at once: that can remove useful evidence and leave you unsure which change affected the result.
If you can safely do so, make a brief note of the current scene, output settings and any timestamped warning in Live Control Room before intervening. Do not stop a stream merely to make the diagnosis tidy if an interruption would cause more harm than observing it. The first aim is to identify the boundary where the picture is lost.
Check the OBS preview and scene sources
Look at the OBS preview first. If the picture is absent there too, YouTube cannot receive the intended picture from that scene at that moment. Check that the intended scene is selected, that its sources are visible and not hidden behind another source, and that any media or capture source is still active. A source may have stopped, gone blank or lost its device after a reconnect even while audio continues through a separate source.
For a camera or capture device, check whether OBS still shows an image in its source properties, and whether another application has taken control of the device. For a media source, check whether it is paused, ended or showing an error. If the scene contains multiple layers, toggle visibility carefully and watch the preview; do not delete or rebuild the scene during a live incident unless you have a known working copy.
If the preview has video but the outgoing stream does not, the problem is farther along than scene composition. Check OBS's streaming status, encoder selection and log messages around the reconnect. The OBS Project's stream connection troubleshooting guide explains that dropped frames and intermittent disconnections point to a network issue between the computer and remote ingest server. That guidance helps interpret connection symptoms, but it does not establish that every audio-only incident is a network fault.
OBS preview is a useful first boundary, not a complete test of what went out. A preview can look normal while the encoder or connection has trouble delivering video, which is why a local recording and YouTube's own view matter as well. If you regularly work with OBS sources or a continuous scene, the practical checks in keeping an OBS YouTube stream running after closing SSH may also help you distinguish a running interface from a healthy broadcast.
Review a local recording if available
A local recording made during the affected period is the next useful comparison. Play the portion that covers the reconnect, not just a clip from before the outage. If that file contains sound but no picture, the issue likely occurred before or during local video encoding, so focus on the scene, source and encoder path. If the file contains good video while the YouTube player does not, the fault is more likely between OBS's local output and YouTube's received stream.
A recording is evidence only for the output it captures. OBS recording and streaming can use different output settings or encoder choices, so a healthy recording does not certify that the live output was healthy. Note the recording mode and settings if you know them, and compare timestamps rather than assuming the recording and live player show the same instant.
If you did not record locally, do not treat that absence as a failure or as proof of a YouTube problem. Move to the Live Control Room checks and use OBS preview, logs and any visible encoder warnings as your local evidence. For future streams, choose a recording arrangement that your computer can sustain; recording adds work and storage use, and should be tested rather than enabled blindly on a machine already near its limits.
Keep the file and logs until you have a plausible explanation. A short, intact recording can show whether the source itself went black or whether the live delivery alone lost picture. If you need to verify a source video before building it into a scene, the steps for checking a large video upload before using it in OBS offer a related way to separate a bad input file from a live-stream fault.
Compare YouTube preview and stream health
Open YouTube Live Control Room and inspect the stream preview, health indicator and timestamped errors for the same period. If OBS preview and a local recording both show video but YouTube's preview is black or absent, YouTube is not showing the video you can see locally. Read the exact error rather than guessing from the player alone; a warning about no video stream is different from a warning about keyframe frequency.
YouTube documents live encoder errors, including cases where an ingestion stream has no video stream and where video keyframe frequency is incorrect. Its live encoder error messages can point you towards the kind of issue to investigate. Treat the message as diagnostic evidence, not as proof of a particular cause or a one-click remedy.
A timestamp can matter. Match the warning with OBS's reconnect time and the local recording timeline. A warning that began before the audio-only symptom may be a separate issue; one that starts at the same moment is more relevant. Save or write down the message before making changes, especially if the stream recovers on its own and the evidence disappears from view.
If YouTube preview is delayed, allow for the fact that it may not show the exact instant visible in OBS. Compare what the control room reports over a short observation period and avoid making repeated encoder changes simply because the preview has not updated immediately. YouTube's troubleshooting live stream issues provides further checks for the encoder and stream path.
Choose a recovery step based on where video is missing
Use the checks as a branch, not as a ritual. This comparison summarises what each result suggests and where to investigate next.
| What you observe | Likely boundary to investigate | Practical next check |
|---|---|---|
| OBS preview and local recording both lack video | Scene, source or local video encoding | Confirm scene and source visibility, device state and encoder output; inspect OBS logs |
| OBS preview has video, but local recording does not | Recording path or recording-specific settings | Check recording output and encoder settings; compare with the streaming output configuration |
| OBS preview and recording have video, but YouTube preview does not | Live output, connection or YouTube ingest | Read timestamped Live Control Room errors; confirm video is present in the selected streaming output |
| Video returns in all views, but interruptions or dropped frames persist | Connection stability or sustained bitrate | Check OBS dropped-frame indications and network conditions; test a lower video bitrate if appropriate |
When OBS preview is black, restore the intended source or scene only after confirming what changed. If a camera disappeared, check its connection and device state. If a media source stopped, confirm it is still meant to play. If the preview returns but the stream remains audio-only, continue to the outgoing encoder and YouTube checks rather than assuming the scene change solved delivery.
When OBS and the local file have video but Live Control Room reports no video stream, check whether OBS is sending the expected video output and whether the selected protocol and codecs are supported for your configuration. YouTube's encoder settings, bitrates and resolutions list its guidance for supported configurations. Settings depend on protocol and stream setup, so consult the current page for your own configuration rather than copying a preset without checking.
YouTube recommends CBR and a two-second keyframe interval, and says the interval should not exceed four seconds. If Live Control Room specifically reports incorrect keyframe frequency, inspect that setting in OBS and compare it with YouTube's current guidance. Do not change keyframe cadence merely because a reconnect occurred; use the warning or a settings mismatch as the reason.
If local video looks healthy but OBS reports dropped frames or unstable delivery, investigate connection quality. OBS notes that Wi-Fi can be less stable for streaming and recommends a wired connection; an Ethernet cable is a reasonable test when you are currently using unreliable Wi-Fi. Consider a stable lower video bitrate only if the connection cannot sustain the current one, then observe whether dropped frames change. A lower bitrate can reduce picture quality, so it is a trade-off rather than a universal fix.
Restarting network equipment or testing another network path makes sense when the evidence points to connection trouble, such as dropped frames or intermittent disconnections. It is not a first response to a specific no-video ingest error when local output is already missing its picture. Likewise, changing a stream key is relevant when YouTube reports a key or encoder-start problem, not as a general answer to audio-only output.
Verify that video resumes at the output
After a targeted change, verify each boundary again. Check the OBS preview, then make a short local recording if your setup permits, and inspect the YouTube preview and health indicator. Look for moving picture, not just a thumbnail or a still frame, and confirm audio remains present. A successful reconnect message alone is not the test.
If the YouTube preview returns but the public player still appears black, check from another device and give the player time to catch up before changing the encoder again. Keep track of the moment video resumed and whether the health warning cleared. If the preview remains absent while OBS and the recording are sound, preserve the error text and logs and continue diagnosing the live output or ingest path.
Do not declare the incident resolved solely because one viewer reports that the picture is back. Ask them to refresh only if appropriate, and confirm that the stream continues to show movement after the initial recovery. For a channel where a long interruption matters, explain that the picture is being checked rather than implying that audio confirms everything is normal.
Prevent a repeat with a controlled test
Before the next important broadcast, test the full chain with a short private or otherwise appropriate test stream. Include movement similar to the real programme, as well as audio. YouTube explicitly advises testing before going live with audio and movement similar to the planned stream, and recommends monitoring stream health. Its encoder settings guidance is a useful reference when checking that the intended video configuration is in place.
During that test, watch OBS preview and Live Control Room together. Make a local recording if your computer has enough capacity, then play it back and confirm picture and sound. A static title card can hide a source problem that appears only when a video loop changes, a camera wakes up or a scene switches, so test the parts of the programme that matter to your actual channel.
Keep a small incident note with the OBS version, operating system, protocol, relevant log excerpt, timestamped YouTube message and whether the local recording contained video. That information makes later troubleshooting more specific and helps support teams distinguish a scene issue from an ingest issue. Avoid including your stream key in notes or screenshots shared publicly.
For an always-on channel, continuous operation also means you need a way to notice what viewers actually receive, rather than relying on a connected indicator. StreamNeo can take the computer-offline burden out of a file-based YouTube broadcast by keeping the uploaded video running from the cloud, but it does not replace checking YouTube's output or resolve every OBS fault. If you are planning a separate continuous file stream, the guide to making a 24/7 YouTube stream from a Google Drive video library covers a different operating approach.
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 does OBS reconnect but YouTube still have no video?
A reconnect indicates that the connection returned; it does not establish that the video source, encoder output or YouTube ingest resumed correctly. Compare OBS preview, a local recording from the affected period and Live Control Room to find where the picture disappears.
Should I reset my OBS stream key?
Not unless the evidence points to a key or encoder-start error. A stream key change is not established as a general fix for an audio-only stream, and changing it without a reason can create another connection problem.
What does YouTube's “no video stream” warning mean?
It means YouTube is reporting that it is not receiving a video stream in the ingest it is checking. Confirm that OBS is actually outputting video, then review the exact warning and your protocol and encoder configuration; do not infer that audio meters prove video is present.
What information should I provide when asking for help?
Include the OBS version, operating system, ingest protocol, relevant log lines and the timestamped Live Control Room message. Say whether OBS preview and the local recording had video during the incident, and never share your stream key.