Closing Remote Desktop can change the graphics or audio devices available to the Windows session running OBS, so a stream may lose picture or sound even if OBS still appears open when you reconnect. It is not the only possible cause: first identify whether the picture froze, audio stopped, OBS disconnected from YouTube, or Windows logged off.
Treat those as separate symptoms rather than changing several settings at once. A community report describes an RDP-related graphics device disappearing, and another describes audio loss; neither proves what happens on every VPS. Confirm your provider's session and device behaviour before buying hardware or rebuilding your stream.
Check what changed when the RDP client closed
Start by noting what you did and what stopped. Closing the Remote Desktop window, signing out of Windows, restarting OBS, and letting the VPS shut down are different events. Depending on the client and provider, disconnecting may leave a desktop session running, while signing out ends that session. Do not assume which occurred: ask the provider how its Windows VPS handles each action.
If you can reproduce the issue safely, write down the order of events: was the stream healthy while connected, did you close the client, and what did viewers see afterwards? Check the YouTube Live Control Room after reconnecting, but distinguish its connection indication from whether the picture and sound are actually useful. A process still visible in Task Manager is not proof that capture continued or that viewers received healthy video.
Keep the test narrow. Change one condition at a time, such as disconnecting the client without signing out, and then check the same observable signals. If a stream is important, do not deliberately interrupt a public broadcast just to test; use a private or otherwise suitable test stream where possible. Record Windows and OBS versions, the capture source, the audio source, and the VPS plan or configuration. That information gives support a concrete case to investigate instead of a vague report that “streaming stopped.”
The report most closely matching this question came from an OBS forum user describing a Windows Server 2012 VPS. A forum participant suggested an emulated graphics device associated with RDP was removed on disconnect. This is community guidance, not an official Windows guarantee and not proof that your own provider behaves the same way. The guide to finding the cause of an FFmpeg stream stopping overnight is also useful for the broader habit of separating a symptom from its cause.
Tell a frozen picture from an encoder disconnect
A stream can fail at different points in the chain. OBS captures a source, encodes the output, and sends it over the network to YouTube. If capture fails, the encoder may continue sending the last frame or a blank image. If the encoder loses its connection, YouTube may show a stream interruption even though Windows and the OBS window remain responsive.
After reconnecting, inspect the preview and the encoder's connection status separately. If the preview is frozen or black but OBS still reports an active connection, investigate the source and desktop session first. If the preview changes normally but OBS reports a dropped or failed connection, examine network and transport status. If the whole VPS session has ended, that is a provider or Windows session issue rather than simply a missing OBS source.
These are diagnostic clues, not definitive tests. A preview can be stale, a connection indicator can lag, and reconnecting may itself restore a device or source. Compare what you see in OBS with what YouTube shows, and note when each changed. Avoid treating “OBS is open” as evidence that viewers are receiving a changing picture at an acceptable rate.
If OBS genuinely disconnects from YouTube, check the stream URL and key in Live Control Room and confirm the selected transport is supported by the encoder. YouTube explains RTMPS streaming setup; RTMPS is a secure extension of RTMP. Those settings affect the connection from encoder to YouTube. They cannot restore a graphics device that vanished from the Windows session or recreate a desktop capture source that has stopped updating.
Check whether audio stopped
Listen to the stream or a suitable recording as well as watching the preview. Look at OBS audio meters for the specific source you expect to hear. A silent meter suggests the input is no longer reaching OBS; an active meter with silence on YouTube points elsewhere, such as a muted track, output routing, or an encoding setup. The meter is evidence about the source reaching OBS, not proof that YouTube receives audible audio.
Desktop audio and microphone audio are separate inputs. If only desktop audio disappears after RDP disconnects, a remote audio device or routing change is plausible. If a microphone also fails, check whether it is attached to the VPS at all and whether Windows still exposes it to the session. A VPS may not have a physical audio input, and a remote connection's audio redirection is not necessarily an independent, persistent device.
When reconnecting, check the Windows playback and recording devices and the OBS source selected for each. A device name returning after you open RDP does not establish that it existed while disconnected. The OBS guide on capturing application audio can help distinguish application capture from desktop-device capture. If you are streaming music, the troubleshooting steps for an ambience stream that loses audio after looping address a different failure pattern, but reinforce the value of checking the actual output rather than assuming the source is still audible.
Do not install a virtual audio device as a first response without confirming the provider's supported configuration and your actual signal path. A new device may solve the wrong problem, conflict with the existing routing, or make it harder to tell what changed. Ask whether an audio endpoint persists outside RDP, whether Windows audio services remain active after a client disconnect, and whether the VPS is intended to support the capture workload.
Understand reported RDP graphics and audio device issues
Remote Desktop is not merely a window into an otherwise unchanged physical desktop. Microsoft describes graphics data for a remote session as being encoded on the remote virtual machine and transmitted to the local device. Its documentation discusses Azure Virtual Desktop, Windows 365 and Dev Box, so it provides context about RDP graphics, not proof of how an unspecified VPS handles OBS capture when its client disconnects. See Microsoft's remote desktop graphics encoding documentation.
In some configurations, connecting by RDP can affect the display or graphics device visible to applications. Community reports describe OBS capture freezing when an RDP-related emulated graphics device disappears on disconnect. Audio has a distinct reported failure mode: an OBS discussion attributes desktop silence to a virtual RDP audio device no longer being available. These reports are reasons to investigate, not universal diagnoses. Windows version, provider configuration, GPU support, capture source and session policy all matter.
A discrete or virtual GPU on a VPS does not, by itself, establish that OBS will have a persistent display path after you disconnect. Nor does a screen that works during an RDP session establish that its capture device will survive after it. Ask the host whether it exposes a supported graphics device to a disconnected Windows session, whether the desktop session remains active, and whether the answer applies to your particular plan. Do not buy a GPU, dummy display adapter or capture accessory based only on a forum explanation; the available information does not show that such a purchase would fix your case.
The distinction matters for workflow. If you need a live browser, application, or changing desktop to appear on stream, that capture environment must keep working without your interactive RDP connection. If you only need continuous playback of finished media, you may not need a live desktop at all. Those two jobs have different requirements, and advice for one should not be applied automatically to the other.
Verify whether OBS is still producing useful output
Check the full chain, not just the application window. After reconnecting, confirm the intended source is selected, the preview is changing when it should, audio meters move when sound is expected, and OBS reports whether it is connected. Then compare the output seen in YouTube's Live Control Room or a viewer-side check. A moving preview is encouraging but is not a guarantee of a healthy stream at YouTube; a visible OBS process is weaker evidence still.
For a simple, safe test, use a known changing visual source and a predictable audio source in a test broadcast. Note whether each remains available after disconnecting the client, and whether YouTube continues to show changing output. Avoid changing the encoder, scene, audio device and Windows power settings together: if the result changes, you will not know which adjustment mattered. Keep a short written record of the before and after state.
If the source is a file playlist, check that playback itself continues and that the scene does not depend on a browser window or desktop that disappears. YouTube's encoder overview lists software encoders, standalone hardware encoders and cloud streaming services, including services for prerecorded video. Its encoder options page is a starting point, not an endorsement or compatibility guarantee for a particular provider. A cloud workflow for prerecorded media is not a substitute for live browser or desktop capture.
For existing media, a purpose-built playout workflow can remove the need to keep a Windows capture session alive. StreamNeo is relevant to that narrower case: you upload a video once and provide your YouTube stream key, so continuous playout does not depend on leaving your own computer or an RDP desktop open. It is YouTube-only and does not capture a live browser, desktop, or changing application; if that is what your channel needs, you must preserve a working capture session instead.
Test provider session behaviour before changing settings
Contact the VPS provider with the specific symptom and ask direct questions. Does closing the RDP client leave the same Windows desktop session running, or does the provider log it off? Does the VPS expose a supported display or GPU device when no user is connected? Is there an audio device independent of RDP, and does it persist after disconnect? Can the provider confirm the answer for your Windows image and VPS configuration? Availability varies, so generic Windows advice cannot settle these questions for an unnamed host.
Explain whether you see a frozen image, missing audio, an OBS-to-YouTube disconnect, or a complete session logoff. Include the times you reproduced it, whether you signed out or only disconnected, and what OBS and YouTube showed. Ask support to clarify whether its answer describes the session remaining active or the capture devices remaining available; those are related but not identical conditions.
Once you know what the provider supports, choose based on the job rather than the name of a setting. A persistent desktop or a supported GPU/display configuration may suit dynamic capture if the provider confirms the behaviour. If audio is the only failure, address the audio path specifically. If OBS stays connected and picture and audio continue while YouTube reports a transport problem, investigate the network and RTMPS configuration. If the task is simply repeating finished video, compare a media playout workflow instead of trying to preserve a live desktop that is not needed.
| What you observe | What it points towards | Next check |
|---|---|---|
| Frozen or black picture; OBS still connected | Capture source or graphics/session state may have changed | Check the source and ask whether its display device persists outside RDP |
| Picture continues; audio meters are silent | Audio input or device availability may have changed | Check the selected input and ask whether it exists independently of RDP |
| Preview and meters look active; OBS reports a connection loss | Encoder-to-YouTube transport or network issue is possible | Verify connection status, stream URL, key and supported transport |
| Windows session has ended | Sign-out, session policy or VPS behaviour may be involved | Ask the provider what disconnect and logoff actions do |
The table narrows the next question; it does not prove a cause. If you cannot observe the stream while disconnected, arrange a suitable test view or review evidence after reconnecting. The Windows PC guide to streaming 24/7 Indian music may help when you are evaluating local Windows playout, but it should not be treated as evidence that a VPS session preserves its capture devices.
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
Will disconnecting RDP always stop an OBS stream?
No. Reports describe graphics capture or audio failures associated with RDP disconnect, but they do not establish that every VPS, Windows version, or OBS setup fails the same way. Confirm what your provider preserves and diagnose picture, sound and encoder connection separately.
OBS is still open after I reconnect. Does that mean YouTube received the stream?
No. The process can remain present while a capture source has frozen, audio has disappeared, or the YouTube connection has failed. Check the changing preview, audio meters, OBS connection state and what YouTube actually shows; none alone proves the whole chain is healthy.
Should I switch to RTMPS to fix a frozen picture?
Only if you have evidence of an encoder-to-YouTube transport problem and need to verify the connection settings. RTMPS does not restore a missing graphics or audio device, or repair a capture source that stopped updating.
Is a cloud encoder suitable for a live desktop?
Not necessarily. A service intended to play prerecorded media may suit a file-based channel, but it does not automatically capture a live browser or changing desktop. First decide whether your content is finished media or depends on a live interactive source, then choose a workflow that supports that requirement.