If you want several videos to play in a fixed loop, start with OBS’s VLC Video source; you may not need WebSocket automation at all. Use OBS WebSocket when an external client must trigger or control supported source or scene actions, and treat scheduling and recovery as separate jobs.
OBS renders the scene and sends the encoded stream to YouTube. A media source plays the files inside that scene, while a WebSocket client can request supported control actions from OBS. That division matters: a command does not create a schedule, and neither a playlist nor WebSocket alone guarantees uninterrupted playback.
Understand what OBS WebSocket does
OBS WebSocket is a control interface. An external programme connects to OBS and can send supported requests, for example to change a scene or control a source. OBS still does the rendering and streaming; the client is not itself a video player or a replacement for the encoder.
OBS Studio includes WebSocket functionality by default from version 28 onwards. Older releases may require the separate obs-websocket plugin. The OBS Remote Control Guide describes using WebSocket with external tools to automate or control scenes and sources. Read the documentation that matches the version you have installed rather than assuming every example found online applies.
First decide whether you need a fixed lineup or a change triggered by something outside OBS. A devotional channel that repeats a known set of bhajans in order may be served by a playlist source. A local news loop that must change after an external update, or a study stream that switches at specified times, may need a client that decides when to act and then asks OBS to do so.
WebSocket supplies a way to deliver requests, not the reason or time for a change. Your automation client needs its own trigger: a clock, an operator action, or another system event. Its schedule can fail independently of OBS, just as OBS can continue running while a client is disconnected. Keep those responsibilities distinct when designing and testing the channel.
Choose a playlist or controlled changes
For a simple continuous sequence, OBS’s VLC Video source is the most direct starting point. The source can play a playlist, with looping and shuffle available. It is a source feature, rather than proof that a WebSocket client can universally add, remove, or reorder individual playlist entries.
VLC must be installed for the source to work, and its architecture needs to match OBS: 64-bit OBS requires 64-bit VLC. If you are preparing a lineup of phone-recorded clips, the practical work may be file compatibility and ordering rather than writing automation. The guide to converting phone-recorded videos for a YouTube playlist stream is relevant before you assemble the source.
| Approach | Best fit | What you configure | Main trade-off |
|---|---|---|---|
| VLC Video playlist | A fixed ordered or shuffled loop | VLC, source playlist, loop or shuffle behaviour | Little scheduling logic, but less external control over each change |
| WebSocket-controlled sources or scenes | Changes triggered or scheduled outside the playlist | A client, supported OBS requests, and a trigger or schedule | More control, but more components to test and observe |
The table is a starting point, not a promise that every source exposes the same controls. If your requirement is “play these files in order all day”, test the playlist first. If your requirement is “switch to this scene when an operator presses a button” or “change sources according to an external timetable”, investigate the relevant request support and the client that will issue it.
A playlist and a client can coexist, but decide which is responsible for the active media. If a client changes scenes while a playlist is playing, understand whether the playlist continues in the background, restarts when shown, or behaves differently for the chosen source. Verify that behaviour in a test scene, not during a public broadcast.
Prepare the media source or playlist
Install VLC in the architecture required by your OBS installation, then create a VLC Video source in a test scene. Add representative files and configure the order, shuffle, or looping behaviour you actually intend to use. OBS’s media sources guide covers the source options; consult it alongside the controls present in your installed build.
Test more than whether the first frame appears. Play through file boundaries, check that audio is present at a sensible level, and observe what happens when a clip ends or cannot be read. If videos use different audio levels or aspect ratios, note what the viewer will experience as the source advances. A playlist that appears correct in a short preview can still reveal a black interval, unexpected scaling, or a silent file at a transition.
For custom switching, decide what the source arrangement should look like before coding. You might create one source per file and switch visibility, or use scenes that each contain the intended media. These designs have different consequences for transitions, overlays, and state. Do not assume that changing one source’s settings is interchangeable with switching scenes; identify the exact source kind and action your design requires.
Write down the expected sequence and state in plain terms: what should be visible, what triggers the change, what happens if the target is missing, and what an operator should see. This makes it easier to test the client and to explain failures. It also exposes whether a simple VLC loop already satisfies the requirement without custom control.
Connect an external automation client
The WebSocket protocol begins with a Hello/Identify handshake. A client connects to the OBS WebSocket server, receives the server’s Hello information, and then identifies itself. If authentication is enabled and requested, the client must authenticate as part of identification before issuing requests. After successful identification, it can send requests supported by that server version.
Use a client library or implementation that explicitly supports the protocol version in your OBS installation. Then consult the generated obs-websocket protocol documentation for request names, fields, and response behaviour. Do not copy a guessed JSON payload from a tutorial simply because it resembles a request you need. The source type and OBS version can affect what is available and how it is configured.
WebSocket access deserves the same care as other remote control interfaces. Keep authentication enabled and use a password. Do not expose the WebSocket port to untrusted networks; restrict access to the machine or trusted network that needs it. If your setup allows local-only access, prefer that unless there is a clear, secured reason for remote control.
A client can issue a supported request, but it does not decide when a request should happen unless you implement that logic. A time-based change needs a clock and schedule; an operator-triggered change needs an interface and a clear action. A useful first test is one manually triggered change between two scenes, followed by a test of the scheduling mechanism separately.
When your operational problem is that a dedicated computer must remain on to play a prerecorded lineup, compare the workflow with a hosted service rather than assuming WebSocket solves that problem. For example, StreamNeo is designed to take an uploaded video and run it as a YouTube live stream without keeping your computer switched on; that removes the specific burden of leaving a local playback machine running, but it does not change the need to prepare the channel and files carefully.
Match requests to OBS and source versions
Check the OBS version and WebSocket implementation before writing request logic. OBS Studio 28 and newer include WebSocket support; an older installation may depend on a separate plugin, so its available protocol and setup may differ. A code sample for a different server version can fail even if the request seems conceptually right.
Also match the action to the source type. OBS can expose broad scene and source controls, but this does not mean every media source supports every operation or that a playlist-update operation has a universal payload. The research and official material do not establish a general command sequence for changing an individual VLC playlist item. Confirm the request, fields, and source settings against the protocol documentation for your installed version, then validate in a test scene.
Keep a short compatibility record with the OBS version, whether WebSocket is bundled or separately installed, the client library and version, source kind, and the request you verified. This is useful when an update changes behaviour or when someone else has to maintain the channel. Review the matching documentation again after an OBS upgrade before relying on previously working automation.
Avoid building around an unverified field or request name. If the official protocol does not document the exact action you need for that source, choose a different supported arrangement, such as switching between prepared scenes, or keep the playlist under OBS’s own source controls. That may mean less granular control, but it is preferable to a brittle integration whose failure only becomes visible during an unattended stream.
Control sources, scenes, and schedules
A scene switch is useful when each programme segment has a prepared visual layout: for example, a title card, an image, and a media source together. A source-level action is more suitable when the scene stays the same and only one element needs to change. Select based on the visual result you need, then confirm that the corresponding supported request exists for your OBS version.
Do not treat a request as a scheduler. For a daily sequence, the client or a separate scheduler must calculate when to send the request and what to do after a missed trigger. Decide whether an action should be retried, skipped, or require an operator. Consider how a restart affects the schedule: does the client reconstruct the current expected state, or simply wait for the next trigger?
For a small channel, a written run sheet may be adequate if changes are manual. For a more complex lineup, maintain a schedule outside the OBS source configuration and make its owner clear. The schedule should identify the target scene or source and the intended transition, while the client should report whether OBS accepted the request. Keep an operator able to see the current scene and intervene if the wrong segment appears.
Transitions and metadata need deliberate handling. If each video has its own title card or overlay, separate scenes may be easier to reason about than trying to mutate a playlist entry. If you use a fixed loop, test how the source transitions at the end of each file. The guide to looping Hindi videos with FFmpeg describes a different approach to continuous playback; compare its trade-offs if your source workflow, rather than OBS scene control, is the main issue.
Send the stream to YouTube and test it
Configure the encoder stream in YouTube Live Control Room using the server URL and stream key YouTube provides, then enter those details in OBS. Keep the key private. YouTube recommends RTMPS in its live encoder settings guidance; use the current official page when choosing protocol and encoder settings because guidance can change.
The same YouTube guidance lists H.264, H.265/HEVC, and AV1, supports up to 60 frames per second, calls for constant bitrate, and recommends a two-second keyframe interval that should not exceed four seconds. These are YouTube’s stated encoder parameters, not a guarantee that a particular computer or connection can sustain them. Its H.264 table lists 5 Mbps minimum and 14 Mbps recommended at 1080p30. Treat those figures as YouTube’s guidance for that resolution and codec, not a universal target; select settings your stable upload can support and verify the current table.
Before depending on a long-running broadcast, test representative motion and audio, transitions, and the actual content files. Watch the local OBS preview and the YouTube stream, and confirm that the intended source or scene changes are visible to viewers. Check audio at clip boundaries and confirm that the stream remains healthy while the client performs its action. A successful request response is not enough if the resulting programme is wrong or the encoder has stopped sending.
YouTube says streams under 12 hours are automatically archived. That statement does not establish that a 24/7 broadcast will be stored as one uninterrupted video. If preserving the stream matters, review YouTube’s current archive guidance and make a separate recording or retention plan appropriate to your channel.
For a wider setup check, including YouTube ingest and OBS configuration, see how to fix YouTube rejecting a 24/7 recorded class stream from OBS in India. Keep the WebSocket client, media source, encoder, and YouTube health indicators in view as distinct parts of the test. This helps locate whether a failure is in playback, automation, encoding, or delivery.
Before relying on the stream unattended, plan for process, power, storage, and network failures. A WebSocket action cannot restart every component or restore a broken connection by itself. Decide who receives alerts, how to check the channel, and what recovery steps are realistic for your equipment. Test recovery deliberately where practical; do not infer it from a successful short session.
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 WebSocket change the video playing on a 24/7 stream?
It can control supported OBS sources or scenes through documented requests, but the exact operation depends on OBS and the source type. Verify the request and its fields against the protocol documentation for your installed version, then test the result in a scene that is not on air.
Do I need WebSocket to loop several videos?
Not necessarily. OBS’s VLC Video source supports a playlist with looping and optional shuffle, which may be enough for a fixed lineup. WebSocket is useful when an external client must trigger or control supported actions beyond that built-in playback arrangement.
Does WebSocket schedule changes or keep a stream online?
No. A client or scheduler must determine when to send requests, and separate monitoring and recovery plans are needed for failures in OBS, the computer, power, storage, or network. A successful WebSocket connection does not guarantee continuous playback or YouTube delivery.
Which OBS WebSocket version should I use?
OBS Studio 28 and newer include WebSocket functionality by default; older versions may require a separate plugin. Check the protocol documentation matching your installation and source type before implementing requests, especially after upgrading OBS.