SRS can receive a looping video from FFmpeg on an Ubuntu host, but that alone does not make the video appear on YouTube Live. The missing piece is a separately configured outbound relay from SRS to YouTube, or a different design in which FFmpeg publishes directly to YouTube.
This guide walks through the documented SRS and FFmpeg example, YouTube's encoder setup, and the boundary between them. If you only need a prerecorded loop on YouTube and do not need SRS for local ingest or playback, direct publishing is the simpler path.
What this Ubuntu workflow does and does not cover
SRS, short for Simple Realtime Server, is a media server. FFmpeg reads your file and publishes a stream; SRS can receive that stream and make it available through supported output protocols. YouTube Live is the destination platform, with its own ingest URL and stream key. These are separate roles, not interchangeable steps.
The upstream SRS getting-started example shows how to run SRS in Docker and publish a sample file into its RTMP input. It also shows ways to check SRS playback locally. YouTube's guidance, separately, explains how an encoder connects to YouTube using the server URL and stream key supplied in Live Control Room. Neither fact establishes that the basic SRS example forwards its input to YouTube.
That distinction matters when you are following commands late at night: a successful FFmpeg connection to rtmp://.../live/livestream can mean only that SRS is receiving the file. It is not proof that YouTube is receiving it. The guide to running a prerecorded YouTube Live stream on Airtel Broadband covers the direct-to-platform question from a connection-planning angle.
There are two sensible architectures. Direct FFmpeg-to-YouTube has fewer moving parts and is usually easier if you do not need an SRS service. SRS in the middle can be useful when you need its local ingest or playback functions, but it requires a verified outbound relay configuration that is not supplied by the basic example here.
Install and run SRS on Ubuntu
SRS upstream recommends Docker as a convenient way to run the server. Its getting-started material gives this sample command:
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 ossrs/srs:5
The flags publish container ports on the host: 1935 is used for the example RTMP ingest, while the example also exposes 1985 and 8080 for other SRS functions. This is an upstream demonstration, not a hardened production recipe. The SRS repository may show a different image tag and additional ports; verify the current upstream instructions and the tag you intend to run rather than assuming every example is interchangeable.
The --rm -it form is convenient for an interactive test, but it is not a durable service arrangement. For a channel intended to run unattended, decide how the container should start again after a host reboot, how configuration will persist, and which ports actually need to be reachable. Keep management and playback interfaces private unless your setup requires remote access. Open only the ports your chosen design needs, and account for both the Ubuntu firewall and any cloud firewall.
After starting the sample, the SRS guide uses http://localhost:8080/ as a lightweight local check. On the same host, localhost points back to that host; from another computer it points to the other computer, not your Ubuntu server. Docker networking adds another context: a hostname that works inside one container arrangement may not resolve in another. Use the server address reachable from the process doing the publishing, and check Docker's networking behaviour for your installation.
The hosting comparison for a 24/7 YouTube livestream is useful if your next decision is where Ubuntu should run. A cloud host can stay on when your home computer is off, but you remain responsible for the host, network path, storage, and the way the stream process recovers.
Prepare the YouTube Live event
In YouTube Studio, create or schedule the live event and open Live Control Room. Under the stream settings, copy the server URL and stream key. Treat the key like a password: anyone who has it may be able to send a broadcast to the event, so do not paste it into public notes, screenshots, or a shared shell history.
YouTube recommends RTMPS. To use it, reveal and copy the RTMPS URL offered in Live Control Room, using the lock control in the stream settings. Do not construct a URL by changing rtmp to rtmps, or assume a default address; use the exact value YouTube provides. RTMPS wraps RTMP in TLS/SSL, which encrypts the connection. If an SSL connection fails, check the copied scheme and host first; YouTube's setup guidance also points to port 443 when needed and supported by the URL.
The YouTube Live Control Room setup instructions explain where the event details and encoder settings are found. Keep the two copied values available for the process that actually connects to YouTube. In the SRS example below, FFmpeg connects to SRS instead, so those YouTube values are not used by that command.
Loop and publish media with FFmpeg
The SRS guide's loop example uses FFmpeg's -stream_loop -1 option to repeat a file indefinitely and publishes it to an SRS RTMP address. The sample file in that example belongs to the SRS source repository; replace it with a file path that exists and is readable in your own publishing environment.
If FFmpeg runs directly on the Ubuntu host and SRS is listening on its loopback interface, the following is an instructional adaptation of the documented loop and publish pattern:
ffmpeg -stream_loop -1 -re -i /path/to/video.mp4 \
-c copy -f flv rtmp://127.0.0.1:1935/live/livestream
Here, -stream_loop -1 asks FFmpeg to keep repeating the input, -re reads it at its natural rate rather than sending it as fast as possible, and -f flv selects the format expected by the example RTMP publication. -c copy passes through the existing audio and video streams instead of encoding them again. That saves encoding work, but only works when the source streams are acceptable to the receiving service and the eventual platform. If the file has incompatible codecs or timestamps, copying does not repair them; inspect the input and the receiver's errors before choosing a transcoding command.
The destination in this command is SRS on the same host. If FFmpeg runs in a different container or a separate machine, 127.0.0.1 refers to that process's own network context, not automatically to the Ubuntu SRS host. Use an address reachable from the publishing process and follow the Docker network arrangement you selected. The upstream example mentions host.docker.internal in its own context, but that name is not a universal promise for every Linux Docker setup.
You can check whether SRS is receiving and serving the stream using the documented example playback paths, such as http://localhost:8080/live/livestream.m3u8 for HLS or http://localhost:8080/live/livestream.flv for HTTP-FLV. A working local playback test confirms something useful: file, FFmpeg, and SRS are connected. It still does not confirm an outbound YouTube connection.
Identify the SRS-to-YouTube relay step
This is the step not to infer. The SRS command above publishes one stream into SRS. The YouTube instructions describe an encoder publishing to YouTube. The cited basic examples do not provide a verified SRS configuration that takes the received stream and forwards it to YouTube, so do not treat the two examples as though they automatically join together.
If your requirement is simply “repeat this video on YouTube Live”, consider removing SRS from the path and configuring FFmpeg as the encoder that sends directly to the YouTube RTMPS URL with the stream key. That architecture has one ingest connection to troubleshoot. You would need an FFmpeg command and encoding settings suited to the file and YouTube's current guidance; the SRS-targeted command above is not that command, because its destination is SRS.
If you need SRS between the file reader and YouTube, obtain and validate a specific outbound push/forward configuration for the SRS version and deployment you are using. Confirm its syntax from current SRS documentation or other primary project documentation before putting it into a long-running channel. Do not paste an imagined second destination onto the sample command and assume that it means SRS relays the stream. In particular, this guide does not supply or endorse an unverified dual-output FFmpeg command.
The trade-off is operational. Direct publishing means fewer services and fewer network links, but no SRS-local playback layer. An SRS intermediate can provide local ingest and playback functions, but adds a service to operate and a relay behaviour to prove. If you host a persistent encoder on a remote machine, the DigitalOcean droplet guide discusses the separate question of keeping a process running after an SSH session ends.
Choose encoder settings and validate the event
YouTube's encoder guidance specifies constant bitrate encoding (CBR), recommends a two-second keyframe interval, and says keyframes should not be more than four seconds apart. Codec, frame rate, resolution, and bitrate must fit the event and source material. YouTube lists H.264, H.265/HEVC, and AV1 video options, and AAC or MP3 audio; your selected encoder and ingest route must support the combination you use.
YouTube's recommended bitrate table gives examples rather than a single setting for every stream. The figures below are from YouTube's encoder settings page; choose based on your actual codec, resolution, frame rate, and reliable upload capacity.
| Example output | Codec | Minimum bitrate | Recommended bitrate |
|---|---|---|---|
| 720p at 30 fps | H.264 | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | H.264 | 5 Mbps | 14 Mbps |
| 1080p at 30 fps | AV1 or H.265 | 4 Mbps | 10 Mbps |
These figures are not a reason to select the highest row by default. A lower resolution that your connection sustains can be more useful than a higher setting that drops packets or destabilises the broadcast. YouTube advises selecting quality in light of a reliable upload connection and recommends testing the connection. A channel using mostly static devotional artwork may also have different visual needs from a local news loop with motion and text; use representative material during tests.
Read the YouTube encoder settings and bitrate guidance before settling on parameters. Test the actual video and audio that will run, check that the event preview receives a signal, and watch YouTube's stream health indicators. Verify audio level and continuity, image quality, and whether the loop returns to its beginning cleanly. If the file includes licensed music, check the rights and YouTube's current policies separately; correct technical settings do not settle rights questions.
For troubleshooting, locate the failing link before changing parameters. If SRS playback does not work, inspect the FFmpeg log, SRS status, address, port exposure, and container network path. If SRS playback works but YouTube shows no incoming signal, the first question is whether any configured process is actually making the outbound YouTube connection. The bitrate and keyframe settings guide offers additional context on those encoder choices, while YouTube remains the source to check for current requirements.
A loop that appears healthy in a short test can still fail overnight for reasons beyond the file: host restart, process exit, network interruption, or a changed key. Plan to observe the first full cycle and review logs after any interruption. If you choose a self-managed route, establish how you will notice a failure and restart the right component; keeping the command in a terminal window is not a recovery plan.
If the unverified relay boundary is the part you do not want to operate, StreamNeo removes that particular burden by letting you upload the file once and run it as a YouTube stream without keeping your Ubuntu computer on. It is YouTube-only, so it does not replace SRS when your purpose is a self-hosted media server for other workflows.
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 the SRS Ubuntu example broadcast to YouTube by itself?
No. The documented example shows FFmpeg publishing a file into SRS, and YouTube's guide shows an encoder connecting to YouTube. You need a separately verified relay from SRS to YouTube or a direct encoder-to-YouTube design.
Can I use the loop command with any MP4 file?
Not necessarily. -c copy preserves the file's existing streams, so codec, timestamps, and audio format may not suit the receiving path. Test the exact file and inspect FFmpeg and YouTube's stream health messages before relying on it.
Should I use SRS or publish directly from FFmpeg?
Use direct publishing when you only need a prerecorded loop on YouTube and do not need SRS's local ingest or playback functions. Use SRS in the middle only if that layer is useful to you and you have confirmed how it will forward the stream to YouTube.
Is host.docker.internal guaranteed to work on Ubuntu?
No. It appears in an upstream example, but hostname resolution depends on the Docker environment and network arrangement. Check reachability from the exact process that runs FFmpeg, and use an address appropriate to that context.