A black OBS scene usually comes from one of three places: the scene or source in OBS, the encoded output reaching YouTube, or the connection between them. First compare the OBS preview with the YouTube player, then follow the branch that matches what you can actually see.
Do not change bitrate, replace hardware, or rebuild every scene before locating the failure. The preview-versus-viewer method below is a practical diagnostic inference, not an official guarantee that every black screen has the same cause.
Locate where the output goes black
Start with the live scene selected in OBS. Look at the preview and then check the actual YouTube player, preferably from another device or from a trusted viewer on a different connection. Write down which of these descriptions fits:
| What you see | Where to investigate first | What it may suggest |
|---|---|---|
| OBS preview is black and YouTube is black | Scene and source setup in OBS | A hidden, covered, misplaced, inactive, or failed source |
| OBS preview looks correct but YouTube is black | Rendering, encoding, stream connection, or YouTube output | A problem after the scene is composited |
| One source is black but other scene elements work | That source's settings and input | A game, file, browser, camera, or capture-device issue |
| The picture freezes or buffers for viewers | Connection and playback conditions | Dropped frames, an unstable delivery path, or viewer-side buffering |
| The picture disappears after content runs for a while | Playback or input continuity | A media file ending, a game stopping its render, or an input signal changing |
This comparison helps narrow the search, but it does not prove the cause. For example, a preview that looks normal does not rule out every OBS performance problem, and a black YouTube player does not automatically mean the bitrate is wrong.
If the YouTube player is still loading rather than showing a clear black frame, treat that as a separate observation. Viewer buffering can depend on the viewer's device, location, and network, even when your stream has not visibly lost its source. Do not use a viewer's buffering report as proof that a particular source in OBS has failed.
Check whether one source or the whole scene is affected
Select the scene that is intended to be live, rather than assuming OBS is showing the scene you meant to use. In the Sources list, confirm that the expected picture source is visible. The eye icon controls visibility, so a source can remain in the scene while being hidden.
Next, inspect the order of the sources. In OBS, sources higher in the list are rendered above sources lower in the list. An opaque image, colour source, browser source, or another full-screen layer can therefore cover a working video source without the video itself being broken. Hide sources above the expected picture one at a time, watching the preview after each change. Restore them once you identify the covering layer.
Select the suspected source and look for its bounding box in the preview. Check whether it has been moved outside the canvas, reduced to an unusably small size, or transformed in a way that leaves no visible area. A source may still be enabled while its position or size prevents you from seeing it.
A useful temporary test is to create a simple duplicate scene containing only the suspected source. This removes other layers from the question. If the source works alone, return to the original scene and inspect the stacking order, masks, filters, and other elements. If it remains black alone, continue with the source-specific checks below.
Keep a note of every change. On an always-on channel, changing several settings at once makes the next failure harder to explain. The aim is not merely to make the preview appear briefly, but to identify which part of the scene stopped producing a picture.
For a longer monitoring routine, see the guide to monitoring a YouTube live stream for dropped frames and disconnects. That is useful after you have separated a source problem from a delivery problem.
Inspect the source type and scene setup
The correct fix depends on what the black source is meant to display. Work through the relevant section rather than applying every OBS remedy to every source.
Game Capture
Check the intended game or window and the selected capture mode. Game Capture has operating-system and application-specific limitations. OBS documents it as a Windows-only source, so on macOS or Linux you need a supported window or screen capture method instead. The OBS Game Capture guide also describes cases where administrator mode, a different capture mode, or a different GPU arrangement may matter.
Some games stop rendering when they are minimised or when a full-screen application is left through an alternate window. That can make a long-running scene appear to fail even though OBS has not changed its scene selection. Test the game in the state in which it will actually run during the broadcast.
On a computer with more than one GPU, OBS and the game may need to use the appropriate GPU for the chosen capture path. Treat this as a compatibility check, not as a reason to change graphics settings at random. If Window Capture shows the game while Game Capture does not, that observation points towards capture compatibility rather than a general failure of the scene.
Media Source or VLC playlist
If the source is a video file, confirm that the file is still available at the configured location and that it plays when tested directly. Then inspect what happens at the end of playback. A single file that reaches its end is not the same case as a playlist configured to continue.
Check the loop setting for Media Source and the playlist behaviour for a VLC Video source. The OBS documentation records different controls and defaults for these source types, but you should not assume that a default matches your current OBS version or the configuration imported into your scene. Confirm the setting on the source itself.
Also check what the source does when playback ends or becomes inactive. A long-running channel can look healthy for hours before a file reaches its final frame. If the picture disappears at a repeatable point in the content, measure that point against the file length before buying hardware or changing the stream bitrate.
For a music or ambience channel, the guide to keeping a YouTube lofi stream playing when a track ends covers the content-continuity side of this problem.
Browser Source
Reload the page and check whether the page's own external dependencies are available. If the browser source displays a web application, inspect whether it has loaded its content rather than assuming that the OBS scene is at fault. This is a practical troubleshooting check, not a documented guarantee that reloading fixes black browser sources.
A complex browser source can also consume GPU or other system resources. If the browser source is the only failed element, first check its page and URL. If the whole scene becomes stale or blank under load, move to the performance branch rather than repeatedly reloading the page.
Camera or capture card
For a webcam, camera, or capture card, confirm that the device is powered, the correct input is selected, and the source has not been taken exclusively by another application. A capture card also needs a working signal from the connected HDMI device. Test the input with another known-good cable, source, or display path only when the evidence points towards the signal chain.
Do not buy a replacement capture card merely because the OBS preview is black. A second device, input, or cable test should first show where the signal disappears. OBS describes video capture sources as inputs for webcams, capture cards, and related devices in its Sources Guide.
Display or Window Capture
Confirm that the intended display or window is selected and that the window is still open. If the application has moved to another display or changed its window state, the source may be capturing a different area from the one you are watching. Platform permissions and supported capture methods can also differ, so check the current OBS and operating-system guidance for your computer rather than assuming a remedy from another platform applies.
Check OBS preview against the viewer output
Once the source appears correct in the preview, compare the preview and the actual YouTube broadcast again. This is the point where you separate scene composition from the path that turns the scene into an encoded stream.
If the preview is black, return to the scene and source checks. If the preview is correct but the viewer sees black, inspect OBS status indicators for rendering lag, encoding overload, dropped frames, or a disconnection. These indicators are not interchangeable. A black source in the preview is not automatically a bitrate problem, while a stream that reaches viewers as a stale or blank picture may justify checking the work OBS is doing after composition.
OBS must use GPU time to composite and render scenes. Each source adds work, and complex browser sources, filters, and layered scenes can exceed what the computer can sustain. If OBS reports rendering lag or encoding overload, reduce competing GPU load, simplify the scene, remove unnecessary browser sources or filters, and consider a lower output resolution or frame rate if the evidence requires it.
These steps address a performance branch. They do not prove that performance caused one particular black source. If a single media file is black while a simple test source remains visible, investigate the media source first. If the entire preview becomes stale or the status indicators show overload, then scene workload becomes more relevant.
If your computer is expected to run through the night, compare its real behaviour with the practical limits discussed in how to run a 24/7 stream on a Chromebook, tablet or low-end laptop. A device can be adequate for a simple media loop and unsuitable for a layered browser-heavy scene.
Investigate disconnects, dropped frames, or buffering separately
A stream can have a healthy scene and still fail to deliver it consistently. Check OBS's connection and dropped-frame indicators only after you know whether the preview itself is producing a picture.
OBS describes dropped frames as a sign of an unstable connection to the remote ingest server or an inability to sustain the configured bitrate. A sufficient number of dropped frames can lead to a disconnection. Look at the pattern rather than reacting to a single viewer message: are dropped frames increasing, does the connection indicator change, or does OBS report a disconnect at the same time as the YouTube player stops updating?
Possible checks include using a wired connection, checking whether a VPN or security software is interfering, updating network drivers, and reducing the configured bitrate when the available upload cannot sustain it. Reducing bitrate may lower quality and should be treated as a troubleshooting change, not as proof of the original cause. Dynamic bitrate can be a workaround in some circumstances, but it does not repair an underlying network problem.
Do not say that OBS caused the disconnection simply because OBS is the software displaying the warning. Network conditions can be outside OBS's control. Similarly, a viewer who reports constant loading may be experiencing a local playback condition even when the stream has no dropped frames. Compare the player from another connection and review OBS's own status before changing the source.
If the preview is already black, changing bitrate should not be your first response. A delivery setting cannot restore a hidden source, a covered layer, a game that is not rendering, or a media file that has reached its end.
Test a change before relying on it in a 24/7 stream
Make one controlled change, then observe the result in the preview and in the live player. For example, hide the top source covering a video, change a Game Capture mode, enable the relevant media loop, or simplify a browser-heavy scene. Record the time and the result so that you can tell whether the change solved the cause or merely altered the symptom.
Run the changed setup for long enough to reach the event that previously caused the failure. If a video disappeared when playback ended, test beyond that point. If a game capture failed after the game was minimised, reproduce that state. If viewers saw buffering during a network change, compare the OBS connection indicators with the player from more than one connection.
Do not rely on a fix because the preview returned after a quick reload. A 24/7 stream needs the source to remain active when files end, windows change, devices sleep, and network conditions vary. The test should match the way the channel will actually be operated.
If the same source repeatedly fails and the evidence identifies an external input problem, then inspect the cable, input device, or capture hardware. Until that evidence exists, software diagnosis is the more useful next step. For a channel that needs the computer switched off after uploading a prepared file, StreamNeo removes the need to keep an OBS scene running locally, while you still need to verify the resulting YouTube output and the content you are authorised to broadcast.
Do not change several scenes, drivers, capture modes, and bitrate settings in one session. That may produce a working broadcast without telling you which change mattered, leaving the next overnight failure just as difficult to diagnose.
Confirm the output in YouTube
After the OBS preview has remained correct, open the live broadcast in YouTube and check the actual player. Confirm that the picture is moving, the expected source is visible, and audio and video continue after the point at which the scene previously went black. If possible, check from a separate device or connection rather than relying only on the computer running OBS.
Use YouTube's current official live-streaming guidance for the channel's settings and status messages. Platform behaviour can change, so avoid treating an old screenshot or a third-party checklist as proof that a broadcast is configured correctly. The YouTube Help live-streaming documentation is the appropriate place to check current platform guidance.
If YouTube shows a black or frozen player while OBS remains correct, return to the delivery and encoding branch. If the player is correct but viewers in one location report loading, compare connections before rebuilding the scene. If both OBS and YouTube become black at the same moment, return to the source that disappeared and test its content, capture mode, or input signal.
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 OBS preview black but my YouTube stream still visible?
The preview and the broadcast may not be observed at exactly the same moment, or YouTube may still be showing previously received frames. Check the selected scene, source visibility, stacking order, position, and source type in OBS, then compare the player again. This is a practical diagnostic path, not a guaranteed official rule for every black preview.
Why does only one source in my scene go black?
Start with that source rather than changing the whole stream. A Game Capture source may have a compatibility or window-state issue, a media source may have reached the end, and a camera or capture card may not be receiving an input signal. Test the source in a simple scene and match the checks to its type.
Should I lower my bitrate when OBS goes black?
Only if the evidence points to dropped frames, an unstable connection, or an encoding problem. If the OBS preview itself is black, bitrate is unlikely to be the first place to investigate. Check sources and scene composition before changing delivery settings.
How can I prevent a media loop from going black overnight?
Test the file through its end and check the source's loop or playlist settings. Confirm what happens when playback becomes inactive, because a channel can appear stable until the first file reaches its final frame. Then verify the actual YouTube player beyond that point rather than relying only on the OBS preview.