SRS can receive a stream and relay it, but running its Docker container does not create a YouTube broadcast. For a continuous channel, you need a source such as FFmpeg or OBS, an SRS ingest path if you need a relay, a separate outgoing connection to YouTube, and a plan for monitoring and recovery.
The useful distinction is between a process that is running and a broadcast that is reaching viewers. This guide walks through the components and credentials first, then the documented SRS container example, and finally the separate publishing and operational work needed for an unattended stream.
Map the source, SRS and YouTube roles
Think of the system as a chain: a file, camera or production setup creates the programme; FFmpeg or OBS encodes it and publishes it to SRS; a configured publisher or relay then sends it to YouTube. SRS is the middle component, not the video source and not the destination. It can accept streams and provide other protocols for playback or distribution, but each connection in the chain has to be configured.
A common arrangement is a prerecorded devotional programme encoded by FFmpeg, sent to SRS over RTMP, then forwarded from an outgoing process to YouTube using the server URL and stream key from Live Control Room. With a live camera or OBS production, the source is different, but the roles remain the same. For background on the first hop, see what RTMP ingest means.
SRS's Docker quick start demonstrates publishing a sample stream into SRS and playing it locally. That is useful for checking that SRS accepts an input, but it is not a complete YouTube relay recipe. In particular, a command that publishes to rtmp://localhost/live/livestream does not configure a route to YouTube merely because the container is running.
You may not need SRS at all. A single FFmpeg process can publish directly to YouTube when your needs are simple and you do not need local playback, protocol conversion or several consumers of the same source. SRS adds a useful boundary when you want to test locally or distribute a feed elsewhere, but it also adds another process and another place to diagnose a failure. Decide based on that trade-off rather than treating SRS as a requirement for every 24/7 channel.
Prepare YouTube Live credentials
In YouTube Live Control Room, create or select the live stream and retrieve its server URL and stream key. YouTube's encoder setup instructions tell creators to enter both values in their encoder. The outgoing publisher needs these credentials; the process that publishes into SRS does not automatically acquire them.
Treat the key as a password. Do not put it in a public example, screenshot, shared configuration file, or logs that other people can read. YouTube describes stream keys as password-like and documents how to reset one if it is exposed. If you rotate it, update the outgoing publisher before relying on the next broadcast.
Keep the two legs visibly separate in your notes. The source-to-SRS leg has an SRS address and a stream name, for example an RTMP endpoint on your own host. The SRS-to-YouTube leg uses YouTube's current server URL and the private key. This separation makes it easier to check whether a failure is local ingest or outbound delivery, and avoids the common mistake of pasting the YouTube key into an unrelated inbound command.
YouTube recommends RTMPS for live ingestion. Its encoder settings guidance explains supported protocols and video/audio settings. Use the URL shown for your current stream rather than copying an endpoint from an old tutorial, and confirm any platform changes in the current official instructions.
Run SRS with Docker
SRS's Docker documentation shows a basic container launch with RTMP port 1935 exposed. Its example also maps HTTP port 8080 and API port 1985 for playback and management demonstrations. A minimal relay that only needs RTMP ingest may not need to expose those optional endpoints; expose only the protocols and interfaces your design actually uses, and restrict access to management interfaces.
The documented quick-start command is a foreground demonstration and uses --rm, so the container is removed after it exits. It is suitable for learning and a short test, not by itself a production supervision strategy. The SRS page is labelled v8 while its displayed example uses the ossrs/srs:5 image tag. That mismatch is a reason to check the current image tag and the configuration documentation that matches the deployment you choose, rather than assuming an old command is current.
A typical shape of the published example is:
docker run --rm -it \
-p 1935:1935 \
-p 8080:8080 \
-p 1985:1985 \
ossrs/srs:5
This illustrates port mappings and the foreground nature of the quick start; check the official documentation for the current command and image before using it. Do not copy a demonstration command into a host and assume it will stay running after a terminal closes or after a host restart. For an actual service, choose an operator-managed restart policy or process supervisor, keep configuration persistent, and decide who will receive and act on failure alerts. Those are deployment choices, not guarantees made by the quick-start command.
Test first with a private or otherwise non-public setup where possible. Confirm that the container starts, that the expected port is reachable from the source, and that logs show an incoming publisher. Avoid exposing ports broadly just because they appear in a demo: a port mapping makes a service reachable according to the host's network and firewall configuration.
Publish a source into SRS
With SRS accepting RTMP, configure the source encoder to publish to its reachable address and a stream path. From the same host, the documentation's localhost-style endpoint can help test; from another machine, localhost points to that other machine, so use the SRS host's address or name instead. The source and SRS must agree on the protocol, path and any authentication configuration you add.
For a prerecorded file, FFmpeg can loop an input with -stream_loop -1 and publish the encoded output to SRS. SRS's example demonstrates this input-looping pattern. It repeats the media file; it does not supervise FFmpeg, restart Docker, repair a network outage or renew a YouTube live session. See the separate walkthrough on looping one video with FFmpeg for the source-side mechanics.
For an OBS source, set the custom server and stream key to the SRS ingest endpoint and stream name, not YouTube's key. Check the encoder preview or local playback first. The appropriate source depends on the programme: a single-file loop is straightforward for an ambience channel, while a study playlist or live news loop may need a playlist scheduler, transitions or a human operator. SRS does not create these editorial functions for you.
The first validation target is local. Use one of the playback methods supported by your SRS setup, such as RTMP, HTTP-FLV or HLS if enabled, and confirm that picture and sound arrive without an obvious problem. This establishes that the source-to-SRS hop works. If playback is blank or silent, investigate the encoder output and ingest path before adding YouTube to the diagnosis.
Configure and verify the YouTube delivery leg
Once local ingest is stable, configure the separate outgoing publisher. It must read or receive the stream from SRS and send it to the YouTube server URL with the YouTube stream key. That may be a distinct FFmpeg process or another explicitly configured publishing component. The SRS quick-start local publishing example does not create this second hop, so follow the configuration reference for the version and design you have selected.
YouTube recommends RTMPS and advises testing before going live, then checking stream health. Use the Live Control Room preview and health indicators to see whether YouTube is receiving the expected video and audio. Do not treat a successful connection message in Docker logs as proof that the public broadcast is healthy: YouTube's ingest, processing and broadcast state are separate checks.
Match encoding settings to your source and dependable upload capacity. YouTube's current guidance includes H.264, H.265 and AV1 video, up to 60 fps, a recommended two-second keyframe interval (not exceeding four seconds), AAC or MP3 audio, and constant bitrate (CBR). The specific bitrate guidance varies by codec, resolution and frame rate. For example, YouTube lists H.264 1080p30 at a 5 Mbps minimum and 14 Mbps recommended, and H.264 720p30 at a 3 Mbps minimum and 8 Mbps recommended. These are YouTube-published settings, not a guarantee of image quality or uninterrupted delivery.
| Choice | What it changes | Practical consideration |
|---|---|---|
| Direct FFmpeg-to-YouTube | Removes SRS from the path | Fewer components to operate; less useful if you need local playback or multiple consumers |
| Source-to-SRS-to-YouTube | Adds a relay hop | Separates ingest from delivery and can support local checks, but creates another connection to monitor |
| Looped file | Repeats prerecorded media | Simple source behaviour; the encoder and destination still need supervision |
| Live production | Sends changing camera or OBS output | Requires a source that remains active and an operator or recovery plan for production faults |
| RTMPS delivery | Uses YouTube's recommended secure ingest option | Confirm your chosen outgoing publisher supports the URL and protocol shown in Live Control Room |
For a lofi channel, the video may be static while the audio carries the programme; the audio settings and source continuity still matter. Use the relevant YouTube lo-fi audio bitrate guidance as a starting point, then test the actual programme. Choose a resolution and frame rate you can sustain at the upload end, allow for normal variation in connectivity, and check stream health under the conditions in which the channel will run.
Check continuity and container operation
An always-on channel is a service to operate, not a command to launch once. The host must remain available, the source process must keep producing frames, SRS must accept the feed, and the outgoing publisher must reach YouTube. A restart policy can restart a stopped container, but it cannot correct a bad stream key, an exhausted disk, a broken media file or a source that is producing no audio.
Write down which component owns each recovery action. For example, a supervisor can restart a failed FFmpeg process; Docker or an orchestrator can restart a failed SRS container; a network or power issue may require a person to intervene. Keep configuration outside a disposable container so that replacing the container does not erase the settings you need. Retain enough logs to diagnose repeated failures, but protect credentials from log output and from broad access.
Monitor the whole path rather than only checking whether Docker says “running”. Check that source frames are being published, that SRS sees an active input, that the outgoing publisher is connected, and that Live Control Room continues to show healthy receipt. A lightweight routine should include a test after configuration changes and a periodic check that someone can see and hear the public or preview feed. If the stream matters overnight, decide in advance who receives an alert and what they can do remotely.
Plan for YouTube session behaviour as well. YouTube says streams under 12 hours are automatically archived; do not assume that one continuous session beyond that duration will be archived under the same guidance, or that a session can be handed off invisibly without a tested workflow. Check the current YouTube stream-key and live setup guidance alongside the official Live Control Room instructions when planning how to start, stop or replace a session.
For a small channel, compare the cost of operating these pieces with the value of controlling the pipeline. If maintaining a host, encoder, configuration, alerts and recovery process is the part that repeatedly interrupts your work, StreamNeo removes that specific burden by letting you upload a file once and run the YouTube broadcast with your own computer switched off. It remains YouTube-only, and you still need to prepare the media and channel appropriately.
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 in Docker make my YouTube stream live?
No. Starting the container makes the SRS service available, but it does not supply a video source or configure a publisher to YouTube. You need to publish a source into SRS and separately set up and verify the outgoing YouTube connection.
Does -stream_loop -1 make a stream self-healing?
No. It repeats the FFmpeg input file, which is useful for continuous playback while that process runs. It does not restart a crashed process, restore a lost network connection or reopen a YouTube session after it ends.
Should I use SRS or publish directly from FFmpeg?
Use direct publishing when one source and one destination meet your needs and you prefer fewer components. SRS is worth considering when local playback, a relay boundary, protocol options or multiple consumers matter enough to justify operating another service.
What should I check before leaving the channel unattended?
Test source-to-SRS playback, verify the outgoing publisher and YouTube preview, and confirm stream health with the chosen settings. Then test your restart, alert and recovery arrangements, and check YouTube's current session and archiving guidance rather than assuming a process can run indefinitely without attention.