SRS can receive a continuously looped file from FFmpeg and make that stream available for local playback. To send it to YouTube, you also need a publishing client aimed at YouTube’s current RTMPS ingest endpoint; the SRS quick-start alone does not forward a stream to YouTube or provide a complete 24/7 service.
The useful way to build this is in stages: establish the local path, check playback, then add and test the separate YouTube publishing step. Treat the documented commands as examples of those building blocks, not as proof of unattended recovery, health monitoring, backup media, or suitable hardware sizing.
Understand the separate SRS and YouTube roles
Think of the flow as media file → FFmpeg loop → SRS RTMP ingest → local preview. YouTube is a separate destination: a publishing client sends the stream to the RTMPS address and stream credentials shown for your YouTube live setup. The local SRS address and YouTube ingest address serve different purposes.
That distinction matters when diagnosing a failure. If FFmpeg cannot publish to SRS, investigate the local host, container networking, input file, and RTMP path. If local playback works but YouTube does not receive the broadcast, check the publishing client, the YouTube endpoint and credentials, and the live control room. A single command that publishes to SRS should not be described as a YouTube broadcast.
The SRS Getting Started guide demonstrates a Docker-based setup, local publishing, and playback endpoints. Use it to understand the path, while checking the current instructions and image tags before deployment. The SRS project README currently identifies the project as SRS/8.0 and lists Linux and macOS support across x86_64 and ARM-family architectures; its develop branch and tags can change, so confirm compatibility for the version you choose in the project README.
A relay design adds another moving part. If you want SRS to sit between FFmpeg and YouTube, configure an explicit forwarding or publishing component for that second leg. The quick-start shows FFmpeg publishing into SRS and local playback; it does not show the SRS container automatically publishing onward to YouTube.
Prepare a continuously looped FFmpeg input
Start with a file you are entitled to use and that plays cleanly from beginning to end. Check its audio and video, duration, codec, and whether the ending joins acceptably to the beginning. A loop can faithfully repeat an awkward cut or a silent section, so inspect the content before troubleshooting the streaming tools.
The SRS example uses the FFmpeg option -stream_loop -1 to repeat the input. Its illustrative command is:
docker run --rm -it ossrs/srs:encoder ffmpeg \
-stream_loop -1 -re -i doc/source.flv \
-c copy -f flv rtmp://host.docker.internal/live/livestream
Here, -stream_loop -1 tells FFmpeg to repeat the input indefinitely, while -re reads it at its native rate rather than sending it as fast as possible. The example copies the existing streams with -c copy, packages them as FLV, and sends them to the SRS RTMP path. The command’s input, doc/source.flv, is a sample path, not a file that will necessarily exist in your own container. Mount your file or otherwise make it accessible at the path you pass to FFmpeg.
Stream copy avoids re-encoding, but it is only suitable when the source streams and the output requirements are compatible. If a file fails to publish or YouTube rejects the resulting stream, inspect the actual media properties and the platform’s current requirements before choosing to transcode. Transcoding changes the resource and configuration problem: it may improve compatibility, but it consumes compute and introduces additional settings to test. The quick-start does not establish that every file works with copy mode or specify a universal encoding configuration.
The sample’s --rm -it flags are convenient for a foreground demonstration. They do not arrange for an unattended process to start at boot, restart after a failure, or expose alerts when a stream stops. Keep that limitation in view: a command that loops while it is running is not, by itself, a supervised 24/7 deployment.
For a single recording, a file loop is straightforward. If you need a sequence of clips, plan the transitions and filenames as a separate content-management task rather than assuming a one-file example covers a playlist. The guide on FFmpeg playlist filenames with spaces is useful when building a multi-file input, and reducing file size without blurring text covers a distinct preparation concern for visual material.
Send the input to SRS over RTMP
The example publishes to rtmp://host.docker.internal/live/livestream. That URL is an example of a local SRS ingest address. In the documented Docker quick-start, SRS is run with ports 1935, 1985, and 8080 mapped; these are illustrative values for the quick-start, not a declaration that every deployment should expose them in the same way. Follow the current SRS instructions and adapt networking to where FFmpeg and SRS actually run.
The host name host.docker.internal is also context-dependent. It is used in the example so a container can reach a service on its host in supported environments. If you run both containers on a shared Docker network, use the service name and networking arrangement appropriate to that network instead. If FFmpeg runs directly on the same host, it may use a host-local address. Do not copy a host name into a different topology without checking that it resolves from the publisher’s environment.
Use the same application and stream name in the publish path and the playback URL. In the example, the application is live and the stream name is livestream. If you change either side, change the other side accordingly. SRS’s RTMP documentation can help clarify the protocol and path conventions; verify the documentation version that matches your deployment.
Keep the local path simple at first. Start SRS, make one FFmpeg publisher connect, and confirm that SRS sees the stream before adding YouTube. This separates local ingest problems from outbound publishing problems and makes logs easier to interpret. If the publisher cannot connect, check that the SRS process is running, the port is reachable from the publisher, and the application and stream path match.
Validate local playback endpoints
The SRS guide demonstrates ways to play a locally published stream over RTMP, HTTP-FLV, and HLS. For the sample application and stream name, the corresponding illustrative URLs are:
| Playback method | Example URL | What it helps check |
|---|---|---|
| RTMP | rtmp://localhost/live/livestream |
Whether a compatible player can read the SRS stream |
| HTTP-FLV | http://localhost:8080/live/livestream.flv |
Whether the HTTP-FLV endpoint serves the live stream |
| HLS | http://localhost:8080/live/livestream.m3u8 |
Whether HLS playback is available through the mapped HTTP port |
These are quick-start examples, not universal addresses. Replace localhost, the port, application, or stream name to match your setup. A player outside the host cannot use localhost to reach your server; it refers to that viewer’s own device. For remote tests, use an address reachable from that device and apply appropriate network restrictions rather than opening services indiscriminately.
Check more than whether a player opens. Confirm moving video, audible audio where expected, stable playback over a meaningful observation period, and sensible transitions when the file loops. Compare the local preview with the source if you see black frames, a repeated gap, missing audio, or an unexpected aspect ratio. A successful local preview shows that the first path is functioning; it does not prove that YouTube accepts the stream or that the process will recover overnight.
If the stream contains audio, check it at the local endpoint before moving on. A picture without sound may come from the file, stream-copy compatibility, or a later publishing configuration. The audio troubleshooting guide for YouTube playlist streams offers a separate diagnostic path for a common symptom. Do not treat a local test player’s behaviour as a definitive report of YouTube’s ingest health.
Configure a publishing client for YouTube RTMPS
Open the current YouTube live setup and use the ingest address and stream key supplied for the broadcast. Do not paste a real key into documentation, screenshots, public logs, or a command history that other users can read. Treat it as a credential: store it in a protected configuration or secret mechanism appropriate to your host and limit who can access it.
For RTMPS, the protocol and endpoint path must be correct, the connection uses SSL over port 443, and the client must provide the server hostname through SNI. Use the current values presented by YouTube rather than hard-coding an address copied from an old example. Google’s RTMPS ingestion documentation explains the protocol requirements and, for API-created broadcasts, identifies the RTMPS address through cdn.ingestionInfo.rtmpsIngestionAddress. Ordinary creators should use the values shown in their live setup.
There are two practical designs. In one, a separate publishing client reads the local SRS stream and sends it to YouTube. In the other, you configure an explicit SRS-side forwarding or publishing capability. Either way, establish where the second client runs, what source URL it reads, where the YouTube credentials are held, and how it is started and observed. The quick-start command above only covers the first publisher into SRS; it is not a ready-made second leg.
YouTube’s guide describes RTMPS as a good choice for ordinary low-latency user content. Choose the mode that suits your stream and follow the current platform instructions. The stream-key walkthrough for FFmpeg is relevant if your publishing client is FFmpeg, but keep the stream key private and confirm the current YouTube setup values at the time you configure it.
Test credentials and stream health
Test the YouTube leg separately from the SRS leg. First make sure the local stream is playing. Then start the publishing client with the YouTube endpoint and credentials, and check YouTube’s live interface for the incoming signal and any warnings it reports. A connection message from a client is not enough to confirm that the intended broadcast is receiving usable audio and video.
If YouTube does not show an incoming stream, check the endpoint protocol and path, the port and outbound network policy, and whether the client can establish the required TLS connection with the correct SNI hostname. Check that the key belongs to the intended live setup and has not been replaced. Never paste the key into a public support request while sharing logs; redact it first.
Once the stream is visible, check picture, sound, and continuity at the destination. Review the live control room’s current health information and confirm the broadcast is in the state you intended. A local preview and a YouTube preview answer different questions: local playback tests SRS output, while the YouTube interface reports what the platform is receiving. If the YouTube stream reports dropped frames, use the FFmpeg dropped-frame troubleshooting guide to investigate the publishing path and network without assuming that a single setting fixes every cause.
Document a small recovery procedure before leaving the system unattended: where the key is stored, which process publishes each leg, how to restart them, and how to confirm that YouTube is receiving the expected stream again. Test that procedure deliberately. Do not assume that a process reconnects correctly just because it connected successfully once; the cited quick-start does not specify a guaranteed reconnect behaviour.
Add supervision and recovery for production deliberately
A continuous loop is one behaviour of FFmpeg while it remains active. A dependable operating plan has to account for the host, SRS, the media publisher, the YouTube publisher, network access, the source file, and the YouTube account and broadcast state. Those parts can fail independently, so decide what you will observe and who or what will act when one stops.
Run the components under a process supervisor or orchestrator suitable for your environment. Configure restart behaviour deliberately, and decide what constitutes a restart-worthy failure rather than blindly restarting on every exit. Preserve useful logs across restarts, rotate or otherwise manage them, and create an alert path for loss of local ingest and loss of YouTube publishing. The SRS and FFmpeg commands in a getting-started page do not prescribe this operational design.
Separate checks for each stage. For example, a process may exist while its input is stalled; SRS may be running with no publisher attached; local playback may work while YouTube ingest is disconnected. Define a check for the local stream, a check for the publishing client, and a destination-side check using YouTube’s current health view. Pair alerts with a human-readable runbook so someone can distinguish a source-file problem from a credential or network problem.
Plan for recovery of content and credentials as well. Keep a known-good copy of the media file, record how to replace it safely, and know how to rotate a compromised or invalidated stream key. If you need a fallback programme, design and test that source explicitly; the quick-start provides no backup input. Likewise, test what happens after host reboot, network interruption, a failed process, and a YouTube-side interruption. These are tests you add, not capabilities established by the example.
Choose hosting and workload with evidence
You can run SRS on a machine you control or on rented compute. A home host gives you direct control over the equipment but makes power, broadband, router behaviour, maintenance, and physical access part of your responsibility. Rented compute changes who maintains the physical host but does not remove responsibility for the operating system, stream processes, network configuration, credentials, or monitoring. The documentation cited here does not provide a cost comparison between those choices.
The SRS README’s listed operating systems and architectures can help you check broad platform compatibility, but they are not a sizing guide. The official examples do not map resolution, codec, number of streams, copy versus transcoding, memory, CPU, or network conditions to a minimum host specification. Do not infer that a device is adequate simply because its processor family is listed. Measure the workload you intend to run and test it under the conditions you will use.
The same evidence limit applies to choosing a mini PC or an always-on home server. A compact machine may suit someone who wants to host locally, while a rented host may suit someone who does not want to maintain a device at home. The right choice depends on your encoding needs, connection, operating responsibilities, and recovery plan; there is no supported model or minimum specification in the cited quick-start. If you are comparing options, compare responsibilities and tested workload rather than relying on a generic hardware claim.
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 starting SRS make my stream live on YouTube?
No. The quick-start demonstrates FFmpeg publishing into SRS and local playback. You need a separate publishing client or an explicitly configured forwarding component that sends the stream to YouTube’s current RTMPS endpoint with the correct credentials.
Can I use the example command unchanged with my video?
Not necessarily. The example’s sample file path will not automatically refer to your media, and -c copy only works when the source streams and output requirements are compatible. Make your file available to FFmpeg, test the local playback path, and verify the YouTube stream before relying on it.
Does -stream_loop -1 keep a channel running after a failure?
It repeats the input while FFmpeg is running; it does not supervise FFmpeg, restart SRS, or guarantee reconnects. Add and test process supervision, alerts, logs, and a recovery procedure separately.
What hardware do I need for SRS and FFmpeg?
The cited SRS materials list supported architecture families but do not give workload-based CPU, memory, or network requirements. Your needs depend on the media, stream count, and whether you copy or transcode, so test the intended workload rather than treating the quick-start as a sizing recommendation.