A black image in an OBS stream running on Hetzner Cloud is not automatically a network fault. First check whether the preview, a local recording, or only YouTube is black; then use OBS and YouTube’s stream-health information to locate where the picture disappears.
Dropped frames and black video are different symptoms. A source or display problem can produce black pictures while frames are being sent, whereas a delivery problem can interrupt otherwise correct video. Work through the checks below in order, and change one setting at a time.
Identify which picture is black
Start in OBS, not in the Hetzner control panel. Look at the preview in the active scene. If it is black, note whether the whole canvas is empty or only one source is missing. A source may be disabled, hidden behind another layer, outside the canvas, or pointed at an input that is not available to the process running OBS. Check the eye or visibility control beside each source, then inspect the source order and properties.
Make a short local recording using the same scene and output settings. Stop it and play it back on the machine or in the environment where it was created. The result separates several possibilities:
| OBS preview | Local recording | YouTube playback | First place to investigate |
|---|---|---|---|
| Black | Black | Black | Scene, source, display session, or capture support |
| Visible | Black | Black or unavailable | Recording/output configuration or encoder path |
| Visible | Visible | Black | Stream destination, key, ingest, or platform processing |
| Visible but stuttering | Stutters | Stutters or drops | Rendering/encoding capacity or delivery stability |
This is a diagnostic guide, not a guarantee that symptoms fit only one row. A recording made with different settings may not reproduce the live output, and a delayed platform preview can take time to catch up. But if OBS preview and local recording are both black, changing network settings is unlikely to restore a missing source.
Ask yourself, “Why is my OBS screen black?” and “Why is OBS showing a black screen?” The useful next question is what source type and operating system you are using. Display capture, a browser source, a media file, and a camera device have different dependencies; advice for Windows Game Capture, for example, does not apply to a Linux V4L2 device.
Compare OBS evidence with YouTube stream health
Keep two observations side by side: what OBS says about rendering, encoding, and dropped frames, and what YouTube’s live control room reports about the incoming stream. OBS’s dropped frames guidance describes dropped frames as a connection stability or bitrate-capacity issue. That signal concerns delivery; it does not by itself explain why an OBS preview is black.
If the preview and recording contain the picture but YouTube shows black, verify that the intended OBS output is connected to the correct destination and stream key. Check that you have not started a different profile or scene collection than the one you tested. Then review YouTube’s stream health documentation and the status shown in the current live control room. It can help distinguish an incoming stream problem from an image that is already wrong before it leaves OBS.
If OBS reports dropped frames while the preview remains correct, look at delivery stability and bitrate capacity. If OBS reports rendering or encoding overload, investigate local processing instead. A remote stream that is black while a local recording is sound points towards output routing, ingest configuration, or platform-side processing rather than a capture source. Avoid treating any one dashboard message as a verdict about a host.
For an always-on channel, keep a brief record of the time, active scene, OBS status, and YouTube status when a fault occurs. This makes a transient interruption easier to separate from a repeatable scene or session failure. If the issue is a YouTube block or regional restriction rather than a black source, this guide to blocked YouTube streams in India covers that distinct path.
Check scene and capture support
When the preview is black, confirm that the intended source is in the active scene, enabled, and not covered by an opaque image, colour source, or browser layer. Open the source properties and check its selected file, URL, device, or display. A media source can point to a file that is missing from the current machine; a browser source may be blank because its page has not loaded or requires an unavailable resource.
On Linux, make sure the selected source type exists for that operating system. OBS’s video capture sources matrix distinguishes the Windows Video Capture Device source from Video Capture Device (V4L2), the Linux option for supported video devices. If you use V4L2, check that the device is present and that the selected input, format, resolution, and frame rate are supported. The exact available choices depend on the device and driver, so do not copy settings intended for another camera.
A browser or display source also depends on the graphical session being used by OBS. On a headless VM, confirm which user runs OBS and whether that process can access the intended display session. A desktop visible in a remote login window does not prove that a background OBS process has the same display access. If the OBS preview itself is black, establish this before trying encoder presets or changing network routes.
Check Linux display and graphics availability
OBS lists an OpenGL 3.3-compatible GPU and an X window system or Wayland among its Linux and Unix system requirements. These are requirements to consider, not proof that a particular virtual machine exposes a usable display to your OBS process. Confirm the OS, display session, graphics support visible inside the guest, and the account under which the application runs.
Hetzner Cloud instances are virtual machines. Hetzner’s Cloud documentation describes its Cloud server environment, while its technical documentation discusses KVM and virtio. Those facts do not establish that your particular VM has a physical GPU available to OBS or supports GPU passthrough. Do not assume a graphics card can be attached to an existing Cloud VM, or that moving to another Cloud CPU class will provide a display adapter.
If the workload genuinely needs a physical GPU, investigate a hosting product that explicitly documents GPU hardware and confirm its current configuration, availability, and cost with the vendor. Hetzner documents GPU servers separately from Cloud VMs, but moving hosts is not a general black-video remedy. Source compatibility, drivers, display access, and the way OBS is launched still matter. A dedicated CPU can make CPU availability more predictable, but does not create a missing capture source or graphics session.
The right choice depends on the cause you have established. If a video file source is absent, correct the file path. If a display source cannot access a session, correct the session design. If rendering is overloaded, assess scene complexity and available graphics resources. Only consider a different host when the diagnosed workload really requires hardware or capabilities that the current VM does not expose.
Check timing and frame-loss signals
OBS can show dropped frames, rendering lag, or encoding lag. They describe different parts of the path. Dropped frames generally point towards connection stability or whether the connection can sustain the configured bitrate. Rendering lag suggests OBS cannot render/composite frames in time; encoding lag suggests the encoder cannot process them quickly enough. Check the OBS stats window and log around the time of the problem, rather than inferring the cause from a black image alone.
A constant frame rate in the settings does not mean that each frame is actually produced and delivered on schedule. When the scene is visible but movement stutters or frames are skipped, compare the OBS timing information with the remote stream’s health. A source may itself update irregularly, so test with a simple, known-good media source before deciding the encoder is at fault. Do not change frame rate, bitrate, and encoder together: that removes the evidence needed to see which change mattered.
If YouTube reports the incoming stream is unstable while OBS’s preview and recording are sound, inspect delivery next. If YouTube receives video steadily but OBS indicates rendering or encoding delay, focus on the machine and scene. OBS’s performance troubleshooting advice recommends reducing the work needed to render or encode when performance is the constraint. Apply such changes only when the relevant symptom supports them.
Check whether OBS can keep up
OBS composites sources into a scene and renders that scene before encoding it. A complex scene with several animated browser sources, filters, overlays, or high-resolution media can demand more resources than a simple loop. If the preview is visible but OBS reports rendering or encoding overload, simplify the scene first: temporarily disable non-essential sources and filters, then observe whether the timing indicators change.
Next, consider reducing output resolution or frame rate, one change at a time. The choice is a trade-off: lower output demands less work but may reduce detail or smoothness. For a devotional still-image loop with a slow visual background, the channel may tolerate a simpler output more easily than a fast gaming replay. Make a test recording and inspect its appearance before changing the live configuration.
Hardware encoding options such as NVIDIA NVENC, AMD AMF, or Intel QSV are available only with supported hardware and drivers, as OBS documents in its hardware encoding guide. Selecting a hardware encoder changes where encoding work is performed; it does not restore a source that OBS cannot capture, create a Linux display session, or guarantee that scene rendering will keep up. On a Hetzner Cloud VM, first verify what graphics device and driver are actually visible inside the guest.
Software encoding may be appropriate when the CPU has enough capacity for the chosen workload; a hardware encoder may help when supported and properly exposed. Neither choice is a universal remedy for black video. If a test on a simpler scene still shows the same black source, return to source properties and display access rather than continuing to rotate encoder presets.
Inspect outbound delivery stability
Only prioritise the outbound path after local video is correct or OBS reports dropped frames/disconnections. Confirm that OBS is streaming to the intended YouTube destination and that the stream key belongs to the intended broadcast. Treat keys carefully: avoid pasting them into logs or support messages. A wrong destination or stale configuration can send a valid picture somewhere other than the live event you are watching.
Then review bitrate and network stability. OBS associates dropped frames with connection instability or bitrate exceeding available capacity. If the path is constrained, reducing bitrate can help the stream fit the available connection, but the image may lose quality. OBS also notes that dynamically changing bitrate can manage congestion without fixing the underlying cause. Check for sustained instability, packet loss, or a route interruption before attributing the symptom to Hetzner; YouTube ingest, local configuration, and the broader network path can all be relevant.
Hetzner’s virtual network details do not prove that a black preview originates in its network. Likewise, an RTMP-compatible destination does not repair imagery that is already black in OBS. Hetzner lists Owncast as a live-streaming application that can accept OBS/RTMP input; that is an alternative destination/server, not a fix for a source or display problem in the OBS preview.
For a stream that goes offline after OBS starts, destination state and platform timing may need separate diagnosis; this guide to cloud streams showing offline after starting addresses that symptom. If OBS itself crashes rather than only showing black, this lofi replay recovery guide covers planning for a restart without confusing recovery with source repair.
Change one variable and retest
Once you have a likely cause, make one reversible change. For a scene issue, test one source or layer. For a Linux capture issue, correct the device or source type. For display access, confirm the same OBS process can see the session. For overload, simplify the scene or lower one output setting. For delivery, adjust bitrate or investigate the connection only after confirming that the local picture is correct.
Record the original value and the time of the change. Make a short local recording, inspect OBS’s preview and stats, then check the incoming stream health before judging the result. A test can appear successful because a transient fault cleared on its own; repeat the observation long enough to see whether the same symptom returns. If a change makes the image worse, revert it rather than layering another adjustment on top.
Avoid changing the host, operating system, encoder, resolution, frame rate, and bitrate in one maintenance window. If the stream improves, you will not know what fixed it; if it fails again, you will have more possible causes. A minimal test scene and the normal production scene are useful comparison points, especially when the channel has browser overlays or multiple media elements.
For channels where keeping a local computer running overnight is itself the recurring operational problem, StreamNeo removes that specific burden by running an uploaded video as a YouTube live stream with the computer switched off. It does not diagnose an OBS source or repair a black image in an existing OBS setup, so first establish whether your content and destination work as intended.
Monitor the stream over time
A single successful test does not show whether a channel will remain stable overnight. Keep a simple incident note with the time, OBS log or stats, active scene, YouTube stream-health status, and whether local recording was affected. Avoid recording the stream key. This gives you a way to compare a repeat fault with the conditions that preceded it, such as a source update, session restart, or network interruption.
After making a change, watch the stream long enough to cover the type of operation that previously failed. For a loop, check that a media source reaches its transition or restart point. For a news loop, confirm that the expected scene switches. For a study channel, verify that overlays or browser sources remain visible after the session has been unattended. The useful interval depends on the content and prior fault; there is no universal duration that guarantees reliability.
Keep a known-good configuration or export of your OBS profile and scene collection before substantial edits. Test recovery steps separately from picture quality: an automatic restart can bring a process back, but it cannot correct an absent file or inaccessible display. If the evidence continues to point at guest-visible graphics capabilities, check the current host product specification rather than relying on assumptions about Cloud VM hardware.
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 screen black but YouTube shows a live stream?
A stream can be active while its picture is black if OBS is sending a black scene or an inaccessible source. Check the active scene, source visibility and properties, then make a local recording; an active status does not prove that the desired image is present.
Why is OBS showing a black screen on Linux?
Check that the source type is supported, that the OBS process can access the intended X11 or Wayland display session, and that the guest meets OBS’s Linux graphics requirements. For video devices, use the supported V4L2 source rather than assuming the Windows capture source is available.
Do dropped frames mean Hetzner is at fault?
No. OBS describes dropped frames as a connection stability or bitrate-capacity problem, but that signal alone does not identify which part of the path is responsible. Compare OBS status with YouTube stream health and separate delivery symptoms from a black preview or recording.
Will a GPU server fix black video?
Only if your diagnosis shows that the workload needs graphics hardware or capabilities missing from the current environment, and the replacement exposes what OBS requires. A GPU does not correct an invalid source, inaccessible display session, or incorrect destination configuration.