Yes, OBS can play a video stored on a network drive when the share is mounted on the computer running OBS and OBS can read the file under its own account. That is a practical condition, not a guarantee that every network-share setup will work.
For a long YouTube stream, confirm that the share stays available, choose the right OBS source, and test playback and audio before going live. A mounted file path is not the same thing as a network stream URL.
When OBS can read a network-drive video
OBS uses sources to build a scene, and a Media Source can play a video file. In this setup, the file remains on a share, but the operating system must present it to OBS as a path that the application can open. OBS's Media Sources guide explains how to add and configure media files; it does not promise that every SMB, NFS, mapped-drive or other share configuration will behave alike.
Think of access as two separate checks. First, the computer needs a working connection to the share. Second, the account running OBS needs permission to open the exact file. Seeing a drive in a file browser under your own login does not prove that a background task or a different Windows account can read it.
The network connection must also remain available during playback. A file that opens at the start of a stream can still fail later if the share disconnects, the computer sleeps, credentials expire, or the connection becomes unreliable. OBS cannot play data it can no longer retrieve. It is sensible to treat the share as one part of the streaming chain that needs monitoring, alongside OBS and the internet connection.
This is different from keeping a video on the same computer as OBS. A local file avoids dependence on the share connection, though it still depends on local storage and the computer staying on. A network drive may be useful when the file library is shared among machines or is too large to keep on the streaming computer, but introduces another point to check. If you are planning a channel around prerecorded video, the broader 24/7 YouTube channel setup guide can help you think through the whole operation rather than just the media path.
Mount the share and check the OBS account
Start by connecting the share using the normal method for the operating system on the machine that runs OBS. Then open the specific video from that mounted location. This confirms that the path exists and that your current session can read it, but make sure the test reflects the account and launch method OBS will actually use.
This detail matters most when OBS starts automatically after a reboot, runs under a scheduled task, or is launched through a separate Windows account. A mapped drive may be visible only in the login session that created it. If OBS runs in another session, the drive letter may not exist there, even though it appears in your desktop file browser. A share path that the operating system exposes consistently to the OBS account can be more useful than assuming a familiar drive letter will always be present.
On any system, check that the account has permission to read the file and that the share is not asking for credentials in a way that blocks unattended playback. Do not put credentials into a stream scene or expose them in a screenshot or recording. If you change how OBS is launched, repeat the access check from that context rather than relying on an earlier interactive test.
Keep the computer awake and the network connection active for the planned stream. Avoid changing, moving or renaming the media while OBS is using it. A share that is available at the beginning but goes offline overnight is not a dependable source for a continuous channel. The OBS Sources Guide describes sources as inputs to a scene; the share is where the input file lives, not a separate guarantee of continuous delivery.
Choose Media Source or VLC Video
For one video, begin with Media Source. Add it to the scene, select the file on the mounted share, and check the source's playback options. OBS lists common formats such as MP4, TS, MOV, FLV, MKV, AVI, GIF and WebM in its documentation. A supported format does not by itself ensure that a particular file will play correctly, so verify the actual file in your scene.
Use VLC Video when you need to play a playlist or want VLC's broader media support. It requires VLC to be installed, and OBS's documented guidance says the VLC architecture should match OBS: use 64-bit VLC with 64-bit OBS. VLC Video also has a network-caching property, with a documented default of 400 ms. That setting may be relevant to playback behaviour, but it is not a guarantee against share interruptions or a measure of your network's available throughput.
| Need | Source to try | What to check |
|---|---|---|
| One video file | Media Source | File path, format, audio and playback behaviour |
| A playlist or library | VLC Video | VLC installation and matching OBS architecture |
| A supported network stream protocol | Media Source URL input | Protocol and URL configuration in OBS documentation |
For a playlist that cycles devotional material, the guide to rotating aarti videos with a playlist file describes another way to organise a sequence. That is not a substitute for testing how your chosen files behave in OBS, but it may help you decide whether a single media source or a playlist-based workflow fits the channel.
Whichever source you choose, keep the media path stable. If you edit the scene after testing, reopen the source properties and confirm OBS still points to the intended file. A quick check of the file name and path can prevent a silent failure caused by a renamed folder or a stale mapping.
A mounted file is not a stream URL
A network drive usually means a file share mounted by the operating system and represented as a path, much as a local disk is. For example, OBS might open a video from a mounted folder. A network stream URL instead points to a stream provided over a protocol. The two inputs have different configuration and failure modes, even though both involve network traffic.
For protocols OBS supports, its instructions may use Media Source with Local File unchecked and the URL entered as the input. The OBS SRT guide and RIST guide show protocol-specific examples. Those instructions do not mean that every share address can be pasted into the URL field, or that every arbitrary URL will be accepted as a stream.
If you have a path to a file on a share, mount the share and select the file as a media file. If you have an actual stream URL, check that its protocol is supported and follow the instructions for that protocol. If you are unsure which you have, ask the person or system that provided the address whether it is a file share or a live stream endpoint. Treating one as the other can lead to a source that never plays, even while the address looks plausible.
Test playback before going live
A source that opens is only the first check. Run a private or otherwise controlled test before relying on it for a public stream. Watch the OBS preview and confirm that video advances, audio is present and correctly routed, and the picture remains stable. Leave it playing long enough to exercise the conditions you expect during the real stream, including the share connection and the computer's normal operating state. OBS and YouTube recommend testing and monitoring, but there is no official test duration specifically for network-share playback.
Listen to the output rather than relying only on the audio meter. Check that the intended audio source is audible, that it does not stop when the video changes, and that levels are appropriate. For a channel where timing matters, the guide on fixing audio sync for recorded video on YouTube Live can help you diagnose a mismatch between picture and sound.
Test the share separately from YouTube upload capacity. A file may read smoothly over the local network while the computer's outgoing connection is insufficient for the selected stream settings, or the upload may be healthy while the share drops. YouTube's streaming tips say the total streaming bitrate cannot exceed available upload bandwidth and recommend leaving 20% headroom. This is guidance for the encoder's upload to YouTube; it does not specify the bandwidth needed to read a file from your share.
If you see interruptions, note when they occur and check the simplest causes first: whether the file still opens under the OBS account, whether the share path changed, whether the connection remained active, and whether OBS reports a source or playback problem. If the source is stable but YouTube reports a poor connection, investigate upload capacity separately. Do not assume one network test proves the other.
Before streaming prerecorded material, also confirm that you have the necessary rights to use it. YouTube says live streams are scanned for third-party content and may be interrupted when a match is detected. Its copyright guidance for live streams and livestream terms explain the relevant requirements; access to a file on a share does not grant permission to rebroadcast it.
Plan around the point of failure
A network share adds a dependency that a local file does not have. If the computer loses access to the share, the media source may stop or fail to continue, depending on the circumstances. For a short programme, you might accept that risk after testing. For a channel expected to run unattended overnight, consider how you will know that playback stopped and what you will do if the share becomes unavailable.
Keep a local copy of essential material if the share's availability is uncertain, or use a workflow with a tested fallback. A fallback is only useful if it is configured and checked before the stream; a backup file in a folder does not automatically become a backup source in the scene. If a black screen appears between clips, this OBS troubleshooting guide for black screens between videos covers a related source-transition problem, though it is not specific to network drives.
If the main difficulty is keeping a computer, mounted share and OBS session available around the clock, StreamNeo can remove the need to leave that computer running for a file-based YouTube stream: you upload the video, provide the YouTube stream key, and the broadcast continues from the cloud with monitoring and automatic restart if it drops. It is YouTube-only, so it is not a replacement for a workflow that specifically needs OBS scenes reading a live network share.
The practical choice is between convenience and the extra dependency. A share can make a central library accessible, but it needs to stay mounted and readable in the exact environment that runs OBS. A local file is simpler to validate, while a cloud-based prerecorded workflow may suit you when leaving a computer on is the part you want to avoid.
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
Can OBS play a video directly from a network drive?
Yes, if the operating system exposes the mounted share as a file path and the account running OBS can read the video. OBS does not guarantee compatibility with every network-share configuration, so test the actual setup before going live.
Should I use Media Source or VLC Video?
Use Media Source as the straightforward starting point for a single file. VLC Video is useful for playlists and extended media support, but it requires VLC installed with an architecture that matches OBS.
Can I paste a network-drive address into the URL field?
Not usually if the address points to a file share rather than a supported network stream. Mount the share and select the file as a media source; use the URL input only for a stream protocol OBS supports.
Does a successful playback test mean the YouTube stream will be stable?
No. You need to check both access to the share and the computer's outgoing upload connection, as well as playback and audio in OBS. A test helps reveal problems but cannot guarantee that a long stream will never be interrupted.