Owncast does not select or loop a video, and it does not make an incoming stream appear on YouTube. To loop a local recording through Owncast, use a separate broadcaster such as OBS to repeat the file and send its RTMP output to Owncast; YouTube requires its own separately configured broadcast path.
This guide follows the Ubuntu self-hosting route for Owncast and covers release matching, FFmpeg, network ports and systemd. The phrase “on YouTube” needs a qualification: this documented workflow loops a file available on your computer, not a video imported from a YouTube page. Nothing here should be read as a claim that Owncast has a built-in outbound YouTube relay.
Understand which job each part does
Think of the workflow as two separate connections. OBS reads and loops the local media file, then sends an RTMP contribution stream to your Owncast installation. Owncast receives that stream and prepares it for people watching through its own player, using HLS segments for delivery. Its documentation describes taking a source stream and converting it to short video segments.
That means Owncast is an ingest and viewing server in this arrangement, not the source picker, loop controller or YouTube destination. If viewers should watch on YouTube, a separate broadcaster must send a compatible stream to YouTube, using the live-stream details YouTube provides. Do not assume that forwarding a stream into Owncast also forwards it elsewhere.
The distinction matters when diagnosing a blank player. If OBS is not looping, the source is at fault. If OBS cannot connect to Owncast, check the Owncast endpoint, key and network path. If Owncast plays correctly but YouTube does not, inspect the separate YouTube encoder and YouTube live setup rather than changing Owncast’s viewer settings.
The official Owncast broadcasting documentation explains how a broadcaster connects to an Owncast server. Its video quality guidance covers output choices and the server’s processing and playback considerations. Neither should be mistaken for instructions to publish a YouTube live stream from Owncast.
Check Ubuntu and FFmpeg before installing
Start by deciding where Owncast will run. It can be hosted on an Ubuntu machine you administer, while OBS runs on a different computer. The server needs enough processing and network capacity for its workload, and it must remain reachable to the broadcaster and viewers. The broadcasting computer, in turn, needs the media file and enough capacity to decode it and produce the outgoing stream.
Use an Owncast release built for the Linux architecture and Ubuntu environment you actually have. Check the project’s current installation notes and release assets before downloading; do not assume a package or command intended for one distribution, processor architecture or release will fit another. The Owncast project repository is the primary place to check its current releases and documentation. Instructions can change, so follow the ones matching your selected release rather than an old copied command.
FFmpeg is part of the media-processing toolchain you should account for when preparing a self-hosted installation. Confirm the installation guidance for the Owncast release you are using, and verify that FFmpeg is installed and callable in the expected environment. A command such as ffmpeg -version can show whether the executable is available, but it does not prove that every codec or input will work as intended. Resolve missing dependencies before moving on to service configuration.
Keep the server’s role and the broadcaster’s role separate when checking prerequisites. OBS and the source file belong on the machine doing the broadcast; Owncast and its configuration belong on the server. A server that can launch Owncast does not necessarily have the resources or access needed to run OBS as well. Conversely, a capable desktop running OBS does not replace a reachable Owncast server.
For a small operation, running both on one machine may be convenient during setup, but it concentrates the work and makes maintenance or a restart affect both functions. Separate machines give you more flexibility, but add network and administration steps. If you need an always-on server, plan how you will patch Ubuntu, inspect logs, protect keys and recover access before treating the installation as unattended.
Install the release that matches your system
Download the Owncast Linux release appropriate to the machine’s architecture from the project’s release source. Read the release-specific instructions for extraction, directory layout, configuration and startup. Check the downloaded asset name and its instructions against your system rather than renaming or substituting a different build because the archive looks similar.
Choose a stable location for the application and its data. Avoid extracting a new release over an active installation without first understanding what is preserved and how configuration and data are handled. Keep a copy of the configuration and make a deliberate update plan; self-hosting gives you control, but it also makes release changes your responsibility.
Before exposing the service publicly, launch it in a controlled way and confirm that it starts without dependency or configuration errors. Use the project’s current instructions for the initial setup and stream key. Change any default key as appropriate and keep the value private: anyone who obtains an ingest key may be able to send a feed to that endpoint. Do not paste it into a public support post or include it in a screenshot.
At this stage, distinguish a server process starting from a stream being available. A running Owncast process can present its web interface while no broadcaster is connected. That is expected: Owncast waits for an incoming source. The local loop is configured later in OBS, not by selecting a file in Owncast’s interface.
Expose only the ports the workflow needs
Owncast uses a web interface for administration and viewing, and accepts incoming RTMP on TCP port 1935 by default. Its documented endpoint pattern is rtmp://yourserver:1935/live/your-stream-key; replace the host and key with your own values. The RTMP port is the path the broadcaster uses to send media to Owncast. It is not the destination for a viewer’s browser.
Before changing a firewall, identify which machine and network boundary you are configuring. A local Ubuntu firewall, a router, and a cloud provider’s network controls may each have separate rules. Permit the web access and RTMP ingest needed by your intended users, but do not open unrelated services simply because a guide’s example does so. Confirm the web port and any configuration changes against the Owncast release instructions you followed.
A working service on the server itself is not evidence that an outside broadcaster can reach it. Test from the network where OBS will run. If a connection times out, check the server address, firewall layers, routing and any port forwarding before changing encoder quality. If the connection is refused, confirm that Owncast is listening on the expected interface and port. Keep the stream key out of diagnostic logs you share.
For internet-facing use, use a considered web-access arrangement and keep the software maintained. The details depend on how you host and publish the service; do not assume that opening a port also provides encryption, access control or protection from unwanted traffic. If you are unsure which boundary blocks a connection, inspect each layer methodically rather than opening a broad range of ports.
Run Owncast with systemd
Once the manual launch works, run Owncast as a systemd service so it can start with the machine and be managed consistently. Create a unit based on the current project guidance and your actual installation paths. The service should run the matching Owncast executable, use the intended working directory and have access to the configuration and data it needs. A copied unit with incorrect paths can fail even when the executable works from an interactive shell.
Use a dedicated, appropriately limited service account where your deployment approach supports it, and grant it access only to the files and directories it needs. Avoid running a long-lived public service as an all-powerful user by habit. Check file ownership after extraction and upgrades, because a service may start manually under your account but fail under its system account when permissions differ.
After adding or changing a unit, have systemd reload its unit definitions, then enable and start the service using the commands appropriate for your unit name. Check the service status and journal output for startup errors. Verify that the service returns after a planned restart of the host. A service that is merely enabled has not yet been proven to start correctly after a reboot.
Systemd can restart a process after it exits, depending on the unit’s policy, but that is not the same as guaranteeing a healthy broadcast. It cannot repair a bad stream key, unavailable media file on the OBS computer, broken network route or incompatible encoder output. Treat service restart as one recovery mechanism and keep a way to review status and logs when something goes wrong.
Configure OBS to loop a local recording
On the computer that can read the file, create an OBS scene and add a Media Source pointing to the local recording. OBS supports common video formats including MP4, TS, MOV, FLV, MKV, AVI, GIF and WebM; actual playback still depends on the file and the installed environment. Enable the source’s Loop option to replay the file after it ends. OBS documents that Loop is off by default, so check the setting rather than inferring it from a preview.
For several recordings, use OBS’s VLC Video source, add the playlist and enable Loop Playlist. That source requires VLC, and the OBS documentation notes that 64-bit OBS requires 64-bit VLC. This is a practical choice when you want a sequence of local files rather than one recording repeated from its beginning. For a single file, Media Source avoids the VLC dependency and has fewer moving parts.
| Need | OBS source | What to check |
|---|---|---|
| Repeat one local recording | Media Source | Select the file and enable Loop |
| Repeat a playlist of local recordings | VLC Video | Install compatible VLC and enable Loop Playlist |
The OBS Media Sources guide documents these source properties. If you are building a long-running OBS workflow, also review the practical advice on keeping a 24/7 stream running when a PC sleeps. Sleep settings are only one part of reliability: power, updates, network changes and OBS itself still need attention.
In OBS, configure the stream destination as Owncast’s RTMP endpoint and provide the private stream key in the broadcaster’s stream settings. Follow the endpoint pattern documented for your installation, including the /live/ path. Send a short test first and confirm that the Owncast player shows moving video and audio. A still image in the preview might mean the media is paused or the file has ended without looping.
Choose output quality with the whole path in mind. Owncast recommends H.264 video and AAC audio for compatibility with transcoding and playback, and recommends a two-second keyframe interval; check the current Owncast documentation when setting these values. The machine encoding, server processing, upload capacity and viewer delivery all constrain what is sustainable. Increasing resolution or bitrate can increase load and bandwidth use without fixing a weak network or an incompatible source. For background on planning an outbound connection, see this guide to bandwidth for an RTMP YouTube stream; the specific route and audience still determine your own requirements.
Configure a separate encoder for YouTube
If the intended audience is on YouTube, set up a separate broadcaster-to-YouTube path. YouTube’s live control room provides the stream details for a broadcast; configure an encoder such as OBS with those details and confirm the event is ready under YouTube’s current instructions. This is distinct from the OBS-to-Owncast RTMP destination. An encoder can be configured for one destination at a time unless you deliberately arrange additional output capability, and no such relay is provided simply by installing Owncast.
You may choose to send the same local OBS scene to YouTube directly, while separately sending a feed to Owncast using a suitable multi-output arrangement, or operate separate broadcaster instances for separate destinations. Each approach has its own resource and operational costs. Do not assume a second output is free: encoding twice can demand more CPU, and duplicate network uploads consume more upstream capacity. Test the chosen arrangement before relying on it.
A YouTube-hosted video is not the local file described in the OBS loop steps. The reviewed Owncast documentation does not establish a way to import a YouTube page’s video and loop it through Owncast. If you have the rights and a local copy of the recording, you can configure OBS to read that local file; the platform and rights implications of what you broadcast are separate questions. Check current YouTube guidance rather than treating this technical setup as a policy determination.
For a channel using pre-recorded material, review YouTube’s copyright considerations for cover songs in prerecorded live streams before scheduling a programme. This is not a substitute for checking the current official rules for your specific content. Likewise, a setup that sends video successfully is not a promise that YouTube will accept, recommend or keep a particular live event available.
If your actual goal is an unattended YouTube loop and not an Owncast viewing server, reconsider whether maintaining both paths is useful. Owncast adds an ingest and viewer service; it does not remove the separate YouTube encoder step. A system designed to keep a local OBS computer awake has different maintenance needs from a server-based workflow, so choose based on who will monitor the machines and how you will recover a failed connection.
Test both paths and plan recovery
Test the Owncast route first. Start the systemd service, open the web interface from the intended viewing network and verify that the broadcaster can connect using the Owncast endpoint. Start the OBS scene and watch the Owncast player through a full loop boundary. Confirm that picture and sound continue when the file returns to its beginning, and check the stream-health information in Owncast’s administration area while the source is active.
Then test YouTube independently. Start the separate encoder output, check the live preview or status available in YouTube’s current live interface, and verify that the event is receiving the expected audio and video. If YouTube fails while Owncast continues, the fault is likely in the separate destination, credentials, event configuration or that network path. If both fail, inspect shared parts such as OBS, the source file, the computer’s connection or the encoder settings.
Test a controlled restart rather than waiting for an overnight failure. Restart Owncast through systemd and confirm its service returns; then check whether OBS reconnects and whether the player resumes. Separately test how the YouTube encoder behaves after a network interruption or planned restart. A restarted service does not necessarily restore the source automatically, and a healthy Owncast process does not confirm that a YouTube broadcast is live.
Use notes that identify what is running where: server address, Owncast service name, OBS scene and source, destination names, and where to check logs. Keep stream keys private and make a recovery copy of configuration. When errors appear, record their timing and which path is affected before changing settings. The guide to common YouTube live streaming errors can help with the YouTube side, but a connection failure to Owncast should be diagnosed against Owncast’s own endpoint and logs.
For a long-running service, review available capacity and delivery quality under real use rather than assuming a configuration is universally suitable. Owncast’s transcoding and HLS delivery use resources, while OBS encoding and uploads draw on the broadcaster’s machine and connection. If viewers report buffering, establish whether the source is stable, the server is keeping up and the viewing connection can receive the stream before increasing output quality.
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
Does Owncast loop a video file by itself?
No. In this workflow, OBS loops a local file or playlist and sends the resulting live feed to Owncast. Owncast receives and serves the stream; it is not the file-looping control.
Will an Owncast stream automatically appear on YouTube?
No. You need a separate, explicitly configured encoder path to YouTube, using the details provided for your YouTube live setup. The Owncast ingest connection does not imply an outbound YouTube relay.
Can I loop a video that is only on a YouTube page?
The workflow described here uses a local file available to OBS. The reviewed Owncast materials do not document importing and looping a YouTube-hosted page through Owncast, so do not plan on that as a supported path.
Should I use Media Source or VLC Video in OBS?
Use Media Source when you want to repeat one local recording and enable its Loop option. Use VLC Video for a playlist, with VLC installed in a version compatible with OBS; then enable Loop Playlist.