A black picture in an OBS stream hosted on an OVHcloud VPS can begin in the scene, during rendering or encoding, or on the route to YouTube. Compare the OBS preview, a local recording and YouTube’s Live Control Room preview in that order; the first place the picture disappears narrows the checks.
There is no single fix established for every OVHcloud VPS. The product, guest operating system, visible graphics device, OBS version and capture source all matter, so verify those details before changing drivers or moving to a different instance.
Find the first point where video goes black
Start with a short, controlled test rather than changing several settings at once. Use the scene and media that normally produce the problem, and note whether the picture is visible in OBS, in a saved recording and in Live Control Room. If the stream is already public, keep the test brief and tell viewers what to expect; for a planned broadcast, test before the event.
The sequence separates two broad classes of fault. If the OBS preview is black, investigate the scene, source, capture method and graphics rendering in the VPS. If the preview and local recording look right but YouTube’s preview does not, inspect the encoder output and stream health, then test outbound connectivity. These are useful branches, not proof of a particular root cause.
Also distinguish a black image from a delayed preview, a frozen frame, or a stream that has not started. Live video can take time to appear after the encoder connects. Read the status text in YouTube Studio’s Live Control Room and OBS rather than treating every blank preview as the same failure.
Keep a small record of the test: operating system and version, OBS version, scene and source type, whether each preview showed the image, any OBS warnings, and the Live Control Room status. This avoids repeating checks and makes it easier to ask OVHcloud or OBS support a precise question. For background on choosing a host for a continuous channel, see this guide to VPS considerations for a 24/7 YouTube stream, but do not assume its general advice proves a particular VPS has the graphics capability your OBS setup needs.
Check the OBS preview and selected source
If the OBS preview is black, first confirm that the active scene contains the intended source and that the source is enabled and visible. In the Sources list, check its visibility icon, position and size on the canvas, and whether another opaque source sits above it. Select the source and use its transform or properties to confirm it points to the right item. A media source can be present in the scene but stopped, ended, or aimed at a file path that is not available in the guest system.
The source type determines what should be available to capture. A display capture needs a display surface in the VPS session; a window capture needs the intended window to exist there; a game capture needs a supported game or application context. Browser and media sources have their own content and playback state. A source that works on your desktop computer may not exist in a remote guest session, particularly if the application was launched in a different user session or without an active desktop.
Check the scene while logged into the VPS in the same session that runs OBS. If you use a remote desktop, verify that disconnecting the remote session does not change or remove the display surface being captured. Do not presume that a virtual display behaves like a physical monitor, or that a capture device attached to another computer is available to the VPS. The exact setup matters.
For Windows display capture, OBS documents a newer capture method for supported Windows 10 version 1903 or newer systems with OBS 27 or newer. Its guidance also covers historical multi-GPU capture problems. Those laptop-specific remedies do not automatically apply to a virtual machine: first establish which graphics adapters the guest sees, which source type you use, and the OBS version. Consult the OBS display-capture guide before changing capture methods.
If OBS shows the intended image but the recorded or streamed output is black, do not keep changing source visibility at random. That difference points to the output or rendering path, so compare a local recording and check the OBS log and statistics next. The evidence should guide the next change.
Compare a local recording or archive
Make a short local recording using the same scene and output resolution as the stream. Play the resulting file outside OBS and check both the start and a later section. A preview may look correct while the saved output is black, frozen or missing a source; the recording gives you a separate view of what OBS has rendered and encoded locally.
If both preview and recording are black, return to the source and rendering checks. If preview is visible but the recording is black, save the OBS log and note the recording encoder and any warnings. The available evidence does not identify one specific setting that explains this difference on an unspecified VPS. Avoid installing capture plug-ins or switching drivers until the OS, source type, OBS version and log give you a reason to do so.
If the recording is healthy but YouTube’s preview is black or unhealthy, the source is less likely to be the first place to investigate. Check whether OBS reports a connection or encoder issue, and read YouTube’s stream-health messages. YouTube’s live streaming troubleshooting guidance recommends checking the encoder, CPU load, source quality and local archive, then examining the outbound connection when local output looks good.
A local recording is also a useful baseline after each change. If you simplify a scene or reduce output demand, repeat the same test and compare the file. That way you can tell whether the change improved rendering locally before attributing any difference in YouTube’s preview to the network.
Review encoder errors and CPU load
Open OBS’s statistics and logs during a test. Look for rendering lag, encoding lag, dropped frames, encoder initialisation failures or warnings that coincide with the black picture. Record the wording rather than paraphrasing it. A warning about an overloaded renderer or encoder is evidence to reduce workload; it is not evidence that every black screen is caused by overload.
OBS composes scenes using graphics resources and then encodes video for output. A complex scene, multiple animated elements, high output resolution or frame rate, and other work using the same resources can leave too little capacity for smooth rendering. If statistics show overload, simplify the scene, close unnecessary applications, or reduce output demand, then repeat the local recording test. Change one factor at a time so the result remains interpretable.
CPU load deserves a separate check. On a VPS, CPU may be the limiting resource even when graphics is available, particularly if the selected encoder uses software encoding. Observe load during the same interval as the problem; a brief idle reading before a test will not tell you what happens under stream workload. If the CPU is persistently saturated, test a lower workload or a suitable encoder setting and compare the result. Do not assume that a hardware encoder exists just because a setting appears in a menu.
For a channel that loops recorded lessons, the checks in this OBS CPU-use guide may help you think through workload reduction. The same principle applies here: use observed load and repeatable tests, rather than changing output settings on the assumption that CPU is the cause.
If the log and statistics show no overload and the local recording is clean, avoid spending time on performance tweaks without evidence. Move to Live Control Room and the connection path.
Check YouTube Live Control Room preview
With OBS sending a test stream, inspect the preview and stream-health area in YouTube Studio’s Live Control Room. Note whether YouTube receives a signal, whether the preview is black or delayed, and any message about the incoming stream. Compare that result with the local recording from the same test. A healthy local file paired with a poor YouTube result shifts attention towards encoding configuration, stream setup or outbound delivery, but does not by itself identify which one.
Confirm that OBS is using the intended stream key and event, especially if the encoder cannot establish a stream or the Live Control Room is waiting for a signal. Treat the key as a credential: do not paste it into support forums or screenshots. If the encoder is connected, use the health messages and OBS log to distinguish a failed connection from a picture that is being delivered in an unsuitable format.
For standard RTMP or RTMPS streaming, YouTube lists supported video codecs and recommends constant bitrate (CBR) and a two-second keyframe interval, with no more than four seconds. Its bitrate guidance varies by codec, resolution and frame rate, so there is no responsible single bitrate to apply to every stream. Choose the actual output format first, then check the current YouTube encoder settings and set OBS accordingly. YouTube recommends RTMPS; use the supported option shown in your current encoder and event setup.
Once the preview appears, watch it with representative motion and audio. A static image may hide problems that show up when a video changes scenes or an animated background moves. YouTube’s live streaming preparation advice recommends testing before the event with similar content and checking quality while live. For audio-specific checks, the YouTube audio format and sample-rate guide is relevant when picture is present but sound is missing or distorted.
Verify OBS graphics and VPS suitability
A VPS label does not establish what graphics hardware or display capability the guest operating system can use. Check the exact OVHcloud product and region, guest OS, device list visible inside the guest, driver state, and whether the session has a display surface. Also note the OBS version and source type. These details determine whether a capture method or encoder can work as configured.
OBS publishes baseline graphics requirements: DirectX 10.1-compatible graphics for Windows and OpenGL 3.3-compatible graphics for Linux or Unix. OBS warns that meeting a baseline does not guarantee a system can stream or record successfully. Treat these as requirements to verify, not a promise that an unspecified OVHcloud VPS can render a scene or capture a desktop.
If the guest has no usable graphics capability for the chosen capture and rendering path, simplify or change the workflow only after confirming the limitation. A prerecorded video source may avoid the need to capture a desktop, but OBS still has to render and encode output. A different capture method will not create a missing display surface or make an incompatible device compatible. Check the OBS system requirements and compare them with the guest’s actual devices and software.
OVHcloud’s documentation describes Public Cloud GPU instances with PCI passthrough, where the guest OS controls the GPU. That is a possible infrastructure route if diagnosis shows that the current guest lacks needed graphics capability, not an automatic fix for source selection, a bad stream key or a YouTube ingest fault. Product model, region and OS image requirements apply. Check OVHcloud’s current GPU instance documentation and its support information before considering a migration; do not infer that an existing VPS plan includes GPU passthrough.
A migration has an operational cost: you will need to verify the image, drivers, OBS behaviour and stream again. If the current setup produces a healthy local recording, replacing the instance before checking the outbound path may add work without addressing the fault. Keep the infrastructure change for a demonstrated limitation.
Test the outbound connection and stream again
If OBS preview and local recording are healthy but YouTube is not, test the outbound path from the VPS. Check the provider’s network information and measure available upload capacity during the same conditions as a stream, without treating a speed test as a guarantee of sustained delivery. Other workloads can consume bandwidth, and a short test may not reproduce an intermittent route problem.
Match the OBS bitrate to the selected codec, resolution and frame rate using YouTube’s current guidance. A bitrate that is too demanding for the available route can produce delivery problems; reducing it indiscriminately can also reduce picture quality. Start from the applicable official recommendation, then use Live Control Room health and repeatable tests to decide whether a change helps. If OBS reports dropped frames due to network conditions, preserve that detail separately from rendering or encoding lag.
Repeat the full comparison after a change: OBS preview, local recording, Live Control Room preview and, if relevant, public playback. The public watch page may lag behind the control room, so it is a later check rather than the first diagnostic signal. Test with movement and audio that resemble the actual channel, and continue to monitor the stream after it starts. For a prerecorded continuous channel, this FFmpeg reconnect guide discusses a different streaming workflow; it is useful context, but it does not replace diagnosing an OBS capture or VPS graphics issue.
Keep a copy of the OBS log and your test notes until the stream is stable. If you need help from OBS or OVHcloud, share the relevant warnings and configuration details while protecting the stream key. A useful report states where the picture first turns black and what the other two checks showed; “YouTube is black” alone leaves the most important distinction unresolved.
If the VPS cannot reliably keep your own computer off and the stream running, you may prefer a workflow built around uploading the video and leaving playback to a hosted service.
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 OBS preview black on my OVHcloud VPS?
First confirm the active scene, source visibility, source properties and whether the display, window or media item actually exists in the guest session. Then check the OBS log and the graphics devices visible to the guest. The VPS name alone does not reveal its graphics capability, and the cause cannot be determined without the OS, source type and test results.
OBS preview looks right, but YouTube is black. What should I check?
Make a local recording and play it back. If that file is healthy, inspect OBS encoder and connection messages, YouTube’s Live Control Room stream health, the stream key and outbound connectivity. Check YouTube’s current codec and bitrate guidance before changing output settings.
Will moving to an OVHcloud GPU instance fix the problem?
Only if tests show the current guest lacks graphics capability needed by the chosen capture or rendering workflow. OVHcloud documents GPU instances as a possible option, but a GPU will not correct a hidden source, invalid stream setup or outbound network fault. Confirm current product and image requirements before moving.
Can I fix a black screen by lowering OBS settings?
Lowering scene or output workload is sensible when logs or statistics show rendering or encoding overload. It is not a universal remedy for a source that is absent or for a connection problem after a clean local recording. Make one change, then repeat the preview, recording and Live Control Room checks.