OBS can loop a local video or playlist and start streaming to YouTube when launched with the right settings. On Ubuntu, though, automatic startup is not the same as running without a desktop: OBS needs an X or Wayland display, so plan to start it in a working graphical user session and test that session after a reboot.
The practical target is an OBS scene configured interactively, then launched for the same Ubuntu user when their desktop session starts. A system service that runs before login may have no display to render into. Treat it as a separate, unverified deployment problem rather than assuming that a startup command turns OBS into a headless process.
How the Ubuntu loop-stream setup works
Think of the setup as three pieces: the media loop, OBS's YouTube connection, and the session that launches OBS. The first two can be configured inside the application. The third determines whether OBS can actually open its interface and render after login or reboot.
For a single prerecorded video, OBS's Media Source can repeat a file. For a sequence of videos, its VLC Video source can play a playlist and repeat it. In either case, the files must remain available at the same paths to the Ubuntu account that opens OBS. If a file is moved, renamed, or stored on a drive that is not mounted at startup, the scene may open without the intended content.
The phrase “background service” can mean simply that you do not want to open OBS manually each morning. That is achievable through a graphical session's startup options, subject to testing. It can also mean a machine starts streaming before anyone logs in and never opens a desktop session. The latter is not what OBS's documented launch parameters establish, and should not be treated as a standard OBS-on-Ubuntu setup.
The OBS Project's Linux installation guidance describes installation routes, but package availability and supported Ubuntu releases can change. Check that page and your distribution's package status before following an old command from a forum or script. Install OBS using a current supported method, then open it as the user who will own the stream.
Do the initial work interactively. Add the source, check its path, preview the scene, set the output options, and connect the YouTube event. This gives you a known-good configuration before you automate launching the programme. If a repeatable playlist rather than one file is the goal, compare the operational differences in playlist rotation options; for a single-file devotional or study loop, repeating the same yoga video all day raises the same basic content-loop question.
Loop a file or playlist in OBS
A Media Source is the direct choice when the stream is one video. Add a Media Source to the scene, point it at the local file, and enable its Loop property. OBS documents common video and audio formats for this source; choose a format your installed OBS version can read and verify playback in the preview before depending on it unattended.
A useful check is to watch the end of the file and the start of the next pass. Look for a black frame, silence, a sudden change in volume, or a visible pause that would be distracting on a public stream. If the source includes audio, confirm the mixer meter responds and that the sound reaches the stream rather than just the preview. A loop that looks continuous may still have a short audio gap at the boundary.
For several clips, use the VLC Video source and load a playlist. OBS notes that VLC must be installed for this source type to be available, and that 64-bit OBS needs 64-bit VLC. The source has a Loop Playlist setting; verify that it is enabled, and check the order and transitions with the actual files. A playlist built on a desktop account may reference relative paths or removable storage, so use stable paths and ensure the startup user can read them.
The choice is not only about the number of clips. A single Media Source is simpler to audit when a single file should repeat. A VLC playlist is more useful when you need a rotation, but it introduces another dependency and more file references to check. Neither option decides whether OBS itself starts in a usable session.
| Requirement | OBS source | What to verify |
|---|---|---|
| Repeat one local video | Media Source | Loop is enabled; the file path is stable; audio and video cross the repeat boundary cleanly |
| Rotate several local videos | VLC Video source | VLC is installed with architecture matching OBS; playlist order and Loop Playlist are correct |
| Change content without rebuilding the scene | Playlist workflow | The playlist and all media remain readable to the Ubuntu user after login |
If your source files are on a network share or external disk, a desktop test is not enough. Reboot and confirm the storage is mounted before OBS launches. Otherwise OBS may start correctly but show a missing-media state, which is a different failure from YouTube connectivity.
Connect OBS to YouTube Live
YouTube's encoder setup instructions describe selecting YouTube in an encoder where available, or using the stream URL and key provided in Live Control Room. In OBS, use the YouTube service integration if it is available and appropriate for your installed version; otherwise enter the server and key in the relevant stream settings. Follow the current YouTube and OBS screens rather than copying a configuration from an old screenshot.
A stream key is a credential. Keep it private as you would a password: do not put the real value in a public systemd unit, shell history, screenshot, support post, or log excerpt. If it may have been exposed, use Live Control Room to reset it. YouTube's stream settings help explains stream configuration and the controls around keys and event behaviour.
An encoder connection does not necessarily mean viewers can see a public live event. For scheduled streams, inspect the Live Control Room preview and event status, and use its controls to go live when required. Auto-start and auto-stop behaviour depends on stream settings; confirm the state for the particular event rather than expecting OBS's launch command to publish it automatically.
Select encoder settings based on YouTube's current recommendations and the upload connection that will carry the stream. YouTube's encoder settings page, accessed in October 2026, recommends H.264 CBR and a two-second keyframe interval, not exceeding four seconds. Its recommended H.264 bitrates vary by resolution and frame rate: for example, it lists 6 Mbps for 720p60 and 14 Mbps for 1080p30. These are recommendations, not a guarantee that a particular broadband connection can sustain a stream. Check the bitrate calculation guide and YouTube's current encoder settings before choosing output settings.
If your upload connection is shared with other people or varies by time of day, a lower output setting that remains stable can be more useful than a higher one that repeatedly drops frames. Test at the intended resolution and frame rate while the ordinary household or workplace network is in use. Watch YouTube's stream health indicators, not just OBS's local preview.
YouTube's encoder help says streams under 12 hours are automatically archived. Do not infer from that rule that a continuous session of several days will be archived in full. If the archive matters, check YouTube's current guidance and plan a session duration appropriate to the event and account configuration.
What --startstreaming does and does not do
OBS supports command-line launch parameters, including --startstreaming. The OBS launch parameters reference documents switches for starting the application in particular ways. This switch can tell OBS to begin streaming as it launches, once the application can start and its stream configuration is available.
It does not install OBS, create a scene, find missing media, log an Ubuntu user into a desktop, supply a display, or make a scheduled YouTube event live regardless of its settings. Nor does the switch by itself provide monitoring or a restart policy. It is a launch instruction, not a complete deployment design.
First launch OBS normally and save the scene collection and profile under the account that will run it. Confirm the correct profile is selected, the stream settings are present, and the media path resolves. Then test the launch parameter from that account's terminal while the graphical desktop is already running. Watch the preview and the YouTube event, and confirm whether the event requires an additional action in Live Control Room.
Do not make an unattended startup command your first streaming test. If a key is wrong, the scene is empty, or the event is not ready, automatic launch merely makes the failure happen sooner and with less visible context. Keep a way to open OBS and inspect its logs and status during the first trials.
Why OBS needs an X or Wayland display
OBS is a graphical application. The OBS Project's system requirements specify that Linux/Unix requires an X window system or Wayland, along with a compatible graphics setup. This is why a command that works from a terminal in your desktop may fail when moved to a system-wide service: the service may not inherit access to the logged-in user's display session.
The display is not simply a monitor plugged into the computer. It is part of the graphical session, with environment and permissions that allow applications to create windows and render. Starting OBS as a different account, or before the desktop has opened, can leave it without the expected display connection. Setting a display variable by guesswork does not necessarily grant access to that session or ensure graphics rendering is available.
This distinction matters on an Ubuntu desktop and even more on a server installation. A machine can have a graphical application installed while no desktop session is active. Conversely, a session can remain active with the monitor switched off, depending on the machine and its power settings. Test the exact configuration you intend to leave running, including what happens when the display sleeps or the user session ends.
A system service may be suitable for tasks that do not need a graphical session, but OBS's requirements and launch documentation do not amount to a supported recipe for running OBS without a display. If your requirement is a machine that streams without any user graphical session, research and validate an alternative design separately; do not call a normal OBS autostart setup a headless daemon.
Plan startup within a graphical user session
The least surprising deployment model is to have the Ubuntu user log into the desktop and let that user's session start OBS. Use the desktop's startup application facility or a user-level service only if you understand how the chosen Ubuntu release manages that session. A user-level unit can be an operational pattern, but it is not a universally reliable OBS configuration: display variables, session timing, audio devices, media permissions, and package behaviour all need validation on the actual machine.
Keep the application and its configuration owned by the same account. That avoids a common mismatch where OBS works in an interactive session but the automated process runs as another user with a different home directory, scene collection, stream profile, or access to media. Avoid running OBS as root merely to bypass a permissions problem; fix ownership and file access for the intended account instead.
Decide explicitly what “automatic” means for your channel. If a person can log in after a reboot, session startup may be sufficient. If the machine must recover unattended after a power cut, an automatic desktop login might be part of the plan, but it changes the security posture of the machine. Consider who can access the Ubuntu account, keep the computer in a controlled location, and avoid storing secrets in scripts that other local users can read.
A user service can be useful for ordering or restarting a process inside a session, but do not assume systemd will know when OBS is ready to render or when YouTube has accepted the stream. A restart loop can repeatedly launch a broken configuration. Start with a manual test, then enable the smallest startup mechanism that solves the actual need. Keep a keyboard, remote desktop, or other way to inspect the active session during commissioning.
StreamNeo is relevant if the problem is specifically keeping a file-based broadcast running while your Ubuntu computer is off: it lets you upload the video and connect the YouTube channel without depending on an OBS desktop session staying open. It is YouTube-only, so that is not a replacement if the point of this setup is learning OBS, using other OBS sources, or controlling a local production from Ubuntu.
Protect the stream key and test reboot behaviour
Treat the YouTube key as confidential throughout setup. Enter it through OBS's settings rather than pasting it into an example command or a unit file that may be copied or backed up. If you need to share a diagnostic, redact the key and account details. If a key appears in public, reset it in Live Control Room and update OBS with the replacement.
Before relying on startup, create a test plan that covers more than the OBS window opening. The OBS Quick Start guide encourages a short test before a first stream, and YouTube recommends testing with representative movement and audio and watching stream health. Use a private or otherwise appropriate test event where possible, and confirm what viewers actually receive.
A practical sequence is to verify the scene and file locally, test the loop boundary, start a short YouTube test, and check sound, picture, and dropped-frame indicators. Then close OBS, launch it again using the intended startup method, and verify that it uses the expected profile. Finally, reboot and observe whether the desktop session appears, whether OBS starts only after the display is available, whether media paths resolve, and whether the YouTube event reaches the intended state.
Also test the failure cases that are realistic for your location: a brief internet interruption, a reconnect, and a normal logout or shutdown. These are checks to perform, not outcomes to assume. Note whether OBS returns on its own, whether you need to sign in again, and whether the YouTube event needs manual attention. Do not leave an untested restart policy to repeat an exposure or public broadcast indefinitely.
For long-running playlists, review resource use and output quality over a representative period rather than relying on a short preview. OBS memory use, source complexity, graphics hardware, and media decoding all affect the local machine; see the OBS memory guidance for long playlist streams for checks relevant to that failure mode. Keep a copy of the original files and configuration somewhere separate from the machine that streams, so a disk problem does not remove the only copy of the content.
When the machine, files, and channel are ready, compare the operating options before choosing a workflow.
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 start streaming automatically when Ubuntu logs in?
Yes, OBS has a --startstreaming launch parameter, and you can arrange for OBS to start from the same user's graphical session. Test the profile, scene, display, and YouTube event together; the parameter does not complete those other steps for you.
Will OBS work as a system service before anyone logs in?
Do not assume so. OBS on Linux requires an X or Wayland display, and a service started outside the graphical session may not have access to one. Validate any specialised arrangement rather than treating it as a standard headless setup.
Can I stream a playlist instead of one video?
Yes. OBS's VLC Video source supports playlists and looping, provided VLC is installed and matches OBS's architecture. Check playlist paths, order, audio, and the repeat boundary after a reboot as well as during an interactive test.
Will YouTube archive a stream that runs continuously for days?
YouTube's cited encoder help says streams under 12 hours are automatically archived; it does not promise that a longer continuous session will be archived in full. Check current YouTube guidance and the settings for your event if the archive is important.