SRS can sit between a video publisher and YouTube, but its basic RTMP example only shows how to publish into SRS. To stream onward to YouTube, you need a separate destination and forwarding configuration verified for the SRS release you deploy.
The practical task is to connect the source, SRS and YouTube without confusing their separate endpoints or assuming a sample loop command provides unattended operation. This guide maps those decisions, covers YouTube's ingest guidance and shows what to validate before treating a stream as continuous.
Map the continuous streaming path
Think of the path as three roles: a source publisher, an SRS ingest point and YouTube's ingest endpoint. FFmpeg or OBS can publish to SRS; SRS can then be configured to forward the feed to YouTube. Alternatively, an encoder can publish directly to YouTube, without SRS in the middle. The correct arrangement depends on why you need SRS and how you plan to manage the stream.
SRS's RTMP documentation gives an example address such as rtmp://localhost/live/livestream. In that example, the address is where FFmpeg or OBS sends a feed into SRS. It is not YouTube's destination URL. YouTube Live Control Room provides a separate ingest URL and stream key for the encoder that sends content to YouTube. Do not combine the SRS example address and YouTube key by guesswork.
For an SRS relay, the conceptual path is:
| Stage | What it does | What you must confirm |
|---|---|---|
| Source publisher | Reads a file or live input and encodes audio and video | It can sustain the intended content and output settings |
| SRS input | Accepts the publisher's RTMP feed | The publisher URL, application and stream name match the deployed configuration |
| Forwarding | Sends the accepted feed onward | The directives and destination format are correct for your precise SRS release |
| YouTube ingest | Receives the forwarded broadcast | The current URL, key, protocol and encoder settings are correct in Live Control Room |
A direct publishing arrangement skips SRS and sends from the encoder to YouTube. That can be simpler if you do not need an intermediate RTMP endpoint or its operational controls. A relay can be useful when your source must publish locally to SRS, but it adds a forwarding step whose behaviour you must verify and monitor. For a related comparison of a local playback tool and the demands of continuous operation, see whether VLC is reliable for a 24/7 YouTube channel from a PC.
Also decide where encrypted transport is used and terminated. YouTube recommends RTMPS; the fact that YouTube accepts RTMP/RTMPS does not establish that every SRS build or every hop in your proposed path supports the exact combination you want. Verify protocol support end to end rather than inferring it from YouTube's encoder list.
Choose and configure the source publisher
Your publisher supplies the media that enters the path. For a recorded programme, it may read a file repeatedly; for a live camera or studio, it captures an ongoing input. SRS's examples use FFmpeg or OBS as publishers. Choose based on the source you actually have and the controls you need, not on a sample command alone.
The SRS Docker getting-started guide demonstrates FFmpeg publishing a looping sample file to SRS with options including -stream_loop -1 and -re. These show how a file can be read repeatedly and paced as media while publishing. They do not, by themselves, provide process supervision, monitoring, recovery after a failure, YouTube event setup, or a complete SRS-to-YouTube forwarding configuration.
Before configuring a publisher, check that the file or live input is valid for the intended stream. Confirm its resolution, frame rate, audio presence, aspect ratio and duration. Test representative motion and sound: a quiet static devotional image and a busy music visualiser can behave differently in encoding, even at the same nominal resolution. If you are building a pre-recorded loop, this guide to creating a looping YouTube live stream with a playlist covers a different source arrangement; it does not replace checks for an SRS relay.
Set the publisher's destination to the SRS input URL only if your design actually uses SRS as an intermediate. The destination should be assembled from the endpoint and stream name defined for your deployment, not copied from an unrelated example without checking its configuration. A local address such as localhost only refers to the machine or container from which the publisher connects; it is not automatically reachable from another computer.
For continuous operation, the publisher also needs a plan for disconnection or process exit. A loop option addresses repetition of a file, not whether the publisher restarts if it stops, whether the input remains readable, or whether a network interruption is recovered. Decide who or what will notice a failure, how it will be restarted, and how you will check that audio and video resume correctly. Test those conditions before relying on the setup overnight.
Set up the SRS RTMP input
SRS needs an RTMP configuration that accepts the publisher's incoming stream. The project documentation includes basic run and publish examples, including a v5 example launched with ./objs/srs -c conf/rtmp.conf; its RTMP page is marked archived. SRS's current Docker getting-started material shows a basic publishing path as well. Treat these as demonstrations of input and basic operation, not as complete production instructions for an onward YouTube relay.
Start by identifying the SRS release and deployment form you intend to run. The official material surfaced for this topic has version caveats: the v5 RTMP page is archived, while the v7 RTMP page is marked unstable. A Docker sample using an image tag does not, on its own, establish which release is the right supported choice for a new production setup. Check the project's current release guidance and choose deliberately; record the exact release so you can verify its documentation and reproduce tests.
Then trace the input settings from publisher to SRS. The application and stream name in the publisher's URL need to correspond to the configuration SRS loads. Check the running process, configuration file and logs, and confirm that SRS sees the expected incoming publisher before debugging YouTube. If the source cannot publish into SRS reliably, forwarding syntax is not yet the problem.
SRS v7's RTMP documentation also describes an idle-publisher timeout and warns that it conflicts with forwarding. That is a reason to review timeout behaviour in the exact version and configuration rather than enabling an apparently helpful idle-kick setting by habit. If the publisher pauses, reconnects or has variable gaps, understand whether the chosen timeout would terminate a feed or interfere with the relay.
Do not publish a stream key in a shared configuration, public screenshot or repository. If a deployment needs credentials, decide how operators will store and enter them without exposing them to viewers or collaborators who do not need access. The SRS input and the YouTube key are distinct parts of the path; a successful connection to one does not prove the other is set correctly.
Obtain YouTube's ingest URL and stream key
Create or open the intended live setup in YouTube Live Control Room and obtain the ingest URL and stream key shown there. YouTube's stream management instructions describe the stream URL and key used by an encoder. Treat the key like a password: YouTube uses it as the credential that lets an encoder send a feed for acceptance by the platform.
Put those details into the component that actually sends to YouTube. In a direct setup, that is the publisher. In a relay setup, it is the verified SRS forwarding configuration, not the publisher's SRS input URL. YouTube recommends RTMPS; when the control room initially displays an ordinary RTMP option, its instructions say to reveal and copy the RTMPS URL. Use the endpoint supplied for the event, not a URL reconstructed from memory.
Before sending, confirm which event the stream key belongs to and that the event is configured as intended. Avoid reusing credentials casually across unrelated broadcasts, and rotate a key if it has been exposed. Keep the URL and key out of article examples, support screenshots and version-controlled files. If more than one person operates the channel, agree who can access the key and who is responsible for replacing it when needed.
A relay does not remove the need to verify YouTube's side. Live Control Room is where you can confirm that YouTube is receiving the feed and inspect its health messages. If YouTube reports no incoming signal, check the outbound hop, destination, credentials and connectivity separately from the publisher-to-SRS input. For a different relay-product workflow, forwarding a live stream in Talk Studio is a useful point of comparison, but its steps should not be transplanted into SRS configuration.
Confirm release-specific forwarding syntax
This is the part where a copy-and-paste recipe can create more confusion than it solves. The basic SRS RTMP examples establish how a publisher can send a stream into SRS. They do not establish, by themselves, that SRS forwards the stream to YouTube, nor do the reviewed official sources establish a complete production forwarding configuration valid across releases.
Before writing or deploying forwarding settings, locate the documentation for the exact SRS release in use and confirm the current syntax, destination URL construction, authentication handling, protocol support and reconnect behaviour. Check any examples against the release's configuration reference and notes. If an example is for a different release, treat it as a clue to investigate, not as production-ready syntax.
Write down the relay as two separately testable connections: publisher to SRS, then SRS to YouTube. For each hop, record which process initiates the connection, which endpoint it targets, which credentials it uses and where errors will appear. That small map makes it easier to tell a local ingest problem from a YouTube destination problem without leaking the key into diagnostic material.
Confirm the behaviour you need, not only whether a configuration parses. Does SRS begin forwarding when the publisher appears? What happens if the publisher disconnects? Does the relay retry the destination, and what happens if YouTube is temporarily unreachable? The answer may depend on the deployed release and configuration. Test these cases in a controlled event before treating the stream as unattended.
Also check whether timeout or idle-publisher settings conflict with the forwarding mode. The SRS v7 RTMP documentation calls out such an interaction. Do not assume a setting documented in one version behaves identically in another, and do not enable timeouts just because they appear to tidy up inactive streams. Record the relevant release-specific guidance alongside your configuration so another operator can maintain it later.
Match YouTube ingest settings to the stream
YouTube's encoder settings guidance lists RTMP/RTMPS, H.264, H.265 (HEVC) or AV1, up to 60 frames per second, AAC or MP3 audio, and constant bitrate (CBR). It recommends a two-second keyframe interval and says not to exceed four seconds. Those are YouTube ingest recommendations, not evidence that your particular SRS build, source encoder and relay all support every listed choice end to end.
Use the table as a reference to YouTube's published figures, not a promise of quality or an instruction to choose the highest row. The correct rate depends on your content, network and full path.
| Example YouTube setting | Published guidance |
|---|---|
| 1080p at 30 fps, H.264 | 5 Mbps minimum; 14 Mbps recommended |
| 1080p at 60 fps, H.264 | 6 Mbps minimum; 17 Mbps recommended |
| Keyframe interval | 2 seconds recommended; do not exceed 4 seconds |
| Audio bitrate | 128 Kbps for stereo; 384 Kbps for 5.1 surround sound |
Select resolution and frame rate that suit the source and viewers. A static picture with devotional audio may not benefit from the same frame rate as a news loop with frequent motion. Use the codec-specific guidance for your choice, and confirm that every encoder and relay stage carries it correctly. If the settings are mismatched, a stream can connect while still producing poor playback or health warnings.
YouTube's streaming tips recommend upload capacity with 20% room beyond the total stream bitrate. Account for all outgoing traffic on the connection, including a backup feed if you use one, and measure the actual connection under the conditions in which the channel will run. Shared broadband, Wi-Fi congestion or other uploads can reduce available headroom after an otherwise promising speed test.
For a first test, keep the configuration modest and use representative content, then inspect stream health before raising resolution or frame rate. Check sound as well as picture, and observe whether the source and relay remain stable over a meaningful period. The bitrate table does not guarantee that a particular link, computer or deployment can sustain a given feed.
Test with YouTube Live Control Room
Test each stage in sequence. First confirm that the publisher reaches SRS and that the expected stream appears in SRS's status or logs. Next verify that the release-specific forwarding path is active and aimed at the URL and key for the intended YouTube event. Finally, use Live Control Room to check that YouTube is receiving the stream and review its stream-health messages.
Do not go public simply because a local RTMP publisher reports success. That confirms only a portion of the path. Confirm picture, audio, frame size and any warnings at YouTube's end. Make a small change at a time if something is wrong: separate an input failure, a forwarding failure and an ingest or encoding warning rather than changing several settings at once.
Run tests with both the ordinary content and expected disruptions in mind. If the source is a loop, let it cross the file boundary and verify the transition. If your network drops or the publisher restarts, observe what happens at each stage and whether a person or process needs to intervene. A continuous stream is an operational arrangement, not a single flag in an encoder command.
Plan the archive separately. YouTube says streams under 12 hours are automatically archived. If the broadcast is intended to last longer and a complete recording matters, arrange recording or segmentation independently rather than expecting one automatic archive to cover the whole run. YouTube's encoder workflow guidance also says to stop sending content to end the stream, so understand how the event should be closed when you do finish.
If you want to avoid keeping a personal computer on to relay a fixed file, that is a separate operational choice from learning SRS. StreamNeo turns an uploaded video into a YouTube live stream, so you do not have to manage a local publisher and its overnight restart path for that file-based use case.
For a more complete picture of unattended playback trade-offs, compare using FFmpeg on a Raspberry Pi for a continuous music stream with the source and recovery requirements of your own setup. The right arrangement depends on whether you need SRS's intermediate ingest, what you can monitor, and how you will recover from a failure.
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
How do I configure SRS to stream to YouTube?
Configure a publisher to send into the SRS RTMP input, then verify the separate SRS-to-YouTube forwarding configuration for the exact release you deployed. The basic RTMP example alone does not forward the stream to YouTube. Obtain the destination URL and key from Live Control Room and test the full path there.
Where do I put the YouTube stream key?
Use it in the component that sends the outbound feed to YouTube: the publisher for a direct setup, or the verified forwarding configuration for an SRS relay. It is not a substitute for the SRS input URL. Keep it private, as you would a password.
What bitrate and keyframe interval should I use for YouTube RTMP?
YouTube recommends a two-second keyframe interval and says not to exceed four seconds; its encoder guidance lists different bitrate figures by resolution and frame rate. For example, its H.264 guidance gives different minimum and recommended figures for 1080p at 30 fps and 60 fps. Match the settings to your content and verify that the source, SRS release, network and YouTube ingest all support them.
How do I keep a YouTube live stream running continuously?
A looped file only repeats media; it does not supervise the publisher, restart a failed relay or restore a broken connection. Plan monitoring and recovery for the source, SRS and network, and test interruptions before relying on the stream unattended. If a complete archive matters, plan recording separately for broadcasts that exceed YouTube's automatic-archive window.