FFmpeg, SRS and YouTube do different jobs in this workflow. FFmpeg reads media and can encode or remux it, SRS provides an RTMP server or relay and can run a configured FFmpeg transcoder, and YouTube receives the finished stream.
SRS's documented ingest takes one input; it does not provide a built-in file-list playlist scheduler. To play several files in sequence, make FFmpeg or a separate script responsible for advancing through them, then publish each input through SRS or use a tested FFmpeg playlist method.
Understand the roles before wiring them together
Think of the path as media files → FFmpeg → SRS → YouTube. The exact order of encoding can vary, but the hand-off matters: SRS is not the owner of a playlist merely because it relays or transcodes a stream. YouTube is the destination, and its Live Control Room supplies the ingest details for the broadcast.
FFmpeg can read a file, sequence inputs when configured to do so, copy compatible audio and video streams without re-encoding, or encode them into a different format and bitrate. SRS can accept an RTMP publish, relay it, or—when configured—start FFmpeg to transcode an incoming stream and publish the result onward. These are distinct operating choices, not synonyms for “playlist streaming”.
The archived SRS v4 ingest guide is explicit that its ingest input accepts one input and that SRS does not ingest a file list. It describes using a script and FFmpeg to publish files one by one. That limitation is important when translating a single-file demo into an always-on channel: a single publish command does not automatically become a queue with transitions, gap handling, or repeat behaviour.
SRS documentation spans releases, and syntax can change. The transcoding discussion here follows the SRS v6 stable FFmpeg guide; the file-list caveat comes from archived v4 ingest documentation. Check the documentation for the release you have installed before copying configuration examples. The live streaming encoder overview is useful if you need to separate the job of an encoder from the job of a relay.
Prepare YouTube's ingest URL and stream key
In YouTube Studio, open the Live Control Room for the stream you intend to run and copy the server URL and stream key shown there into your encoder or publishing configuration. YouTube’s live streaming setup guide describes entering those values in an encoder. A key is a credential associated with the creator’s live setup, not a public URL to publish in an article or share in a screenshot.
Treat the URL and key as separate pieces of configuration. The URL identifies YouTube’s ingest endpoint; the key identifies the stream destination or event configuration. Do not put a real key into a shell command that will be saved in a shared script, terminal history, screenshot, or support message. Keep it in a private configuration location, and replace any example value with the current value from the Control Room.
YouTube recommends RTMPS for encrypted ingest in its encoder settings guidance. SRS documentation also discusses RTMP and RTMPS, but support depends on the precise publishing path and installed release. Prefer the secure ingest URL YouTube provides where available, and confirm that the FFmpeg/SRS combination you plan to use can reach it. Do not assume that an ordinary rtmp:// example is equivalent to a secure destination.
Before building a long-running loop, test with a temporary event or other controlled setup. Make sure you can start a stream, see incoming video and audio in Live Control Room, and stop it cleanly. This exposes URL, credential, and firewall mistakes before a script begins advancing through files unattended.
Choose encoding or remuxing for the media
Remuxing or stream copy means moving already encoded audio and video into the required output container without decoding and encoding them again. It avoids a new encode and may use less processing, but it cannot fix an unsupported codec, change resolution, or lower an unsuitable bitrate. If the source streams are compatible with the output path, copying can be the simpler and less lossy choice.
Re-encoding is appropriate when the source has incompatible codecs, the output bitrate needs to change, or the video and audio settings need to match YouTube’s ingest guidance. It consumes processing capacity and introduces another encode, so test picture quality and sound with the actual source. A static devotional image with music has different motion characteristics from a news loop with moving footage, even though both may be carried by a live stream.
YouTube’s current encoder settings page lists H.264, H.265 and AV1 video options, RTMP/RTMPS protocols, CBR, and up to 60 fps. It recommends a two-second keyframe interval and says not to exceed four seconds. For H.264 at 1080p and 30 fps, its table lists 5 Mbps as a minimum and 14 Mbps as recommended. Those figures apply to that particular row, not to every resolution, frame rate or source. For stereo audio, YouTube recommends AAC at 44.1 kHz and 128 kbps in its advanced settings.
Use YouTube’s row for your chosen resolution and frame rate rather than borrowing a bitrate from an SRS demo. Compare that target with the reliable upload capacity available to the publishing machine or service. If your connection cannot sustain the output, reduce the chosen resolution or bitrate and test again rather than relying on a brief successful start. The bitrate guidance for Indian music streams gives further context for balancing audio and video settings.
SRS v6’s transcoding guide maps configuration values to FFmpeg parameters, including codec, video and audio bitrate, frame rate, dimensions, profile, preset, sample rate, channels and filters. Pay attention to units while translating examples: the guide notes FFmpeg command bitrate parameters are in bits per second, while SRS configuration bitrate values are expressed in kilobits per second. Its copy codec mode is relevant when you do not want to re-encode. Confirm parameter names and units against the guide for your installed release.
Publish one input through SRS
First validate a single file from end to end. Run SRS as the RTMP destination or relay, then have FFmpeg publish one representative file to the SRS application and stream name you have configured. The SRS getting-started guide illustrates a local example in this form: ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream. Here, localhost and the example stream path refer to a local SRS setup, not YouTube credentials or a ready-made production playlist command.
The -re option reads a file at its normal playback rate rather than as fast as the process can consume it. The input is a single file; -c copy requests stream copy; -f flv sets the output format; and the RTMP address points at SRS. The actual input path, application, stream name, codecs and SRS configuration are yours to supply. Avoid pasting an untested demo into a live channel and expecting its sample file or endpoint to exist on your system.
There are two common placements for encoding. You can encode in the publishing FFmpeg process before sending its output to SRS, leaving SRS to relay the result. Or you can send an input to SRS and configure SRS to fork FFmpeg for transcoding, then direct that transcoded output to SRS or another server. SRS v6 documents the latter flow. Choose one owner for final output settings so you know which process controls codec, frame rate and bitrate.
For a YouTube destination, the final publishing hop must use the URL and key from the Live Control Room. In an SRS relay design, configure the relevant forward or output path for that destination according to the installed version’s documentation; in a direct design, configure FFmpeg’s output. Do not confuse a local SRS publish address with YouTube’s ingest URL. The continuous podcast workflow using VLC offers another way to think about a player’s role, but it does not change SRS’s one-input ingest limitation.
Sequence playlist files with a script
For a playlist made of separate files, assign sequencing explicitly. The documented SRS ingest workaround is a script that starts FFmpeg for one file, waits for that publish to finish, and then starts the next. SRS receives each input in turn; the script, not SRS, decides which file is next. The archived guide does not establish a built-in playlist scheduler or universal seamless transition behaviour.
Before writing the loop, decide what “playlist” means for your channel. A study music station might repeat a known set in order; a local news loop might require a fixed order and a deliberate pause for updated material. Decide whether to repeat after the last item, what to do when a file is missing, and whether a gap between publishes is acceptable. A simple sequential script can leave a short discontinuity between files because each process exits and another starts; do not promise a seamless result until you have tested it with the actual media and player behaviour.
An alternative is to use FFmpeg’s own playlist or concat input, where that fits the media and the FFmpeg build. This can put sequencing in one FFmpeg process, but it is not a feature of SRS ingest, and one command does not automatically work for arbitrary formats, mixed stream layouts, looping needs and transitions. Validate the exact input method with copies of the intended files, including the last-to-first transition if the list repeats. The research available for this guide does not verify a universal looped concat command, so it would be misleading to present one as production-ready for every channel.
Whichever approach you choose, make failure behaviour part of the design. A script should make it clear which file is being published, detect a failed FFmpeg process, and avoid silently skipping every file after an error. Keep the YouTube key out of printed logs and shared source code. Test how the publishing chain behaves when one file ends, when a file is unreadable, and when the network or SRS briefly drops. If you use a file list, keep the list and the media paths in a format your script can parse reliably; filenames with spaces and special characters deserve a deliberate test.
If your main requirement is a channel that continues after you switch off your own computer, the difficult part is often not the codec but keeping the playlist process and publishing path alive. StreamNeo removes that specific need to keep a local machine running by taking an uploaded video and broadcasting it to YouTube continuously; it does not replace this SRS/FFmpeg setup when you need a custom relay or a multi-file sequence under your own scripting. For a broader comparison of unattended approaches, see how a study music stream can stay live without a home computer.
Verify the stream in YouTube Live Control Room
Once the single-file route works, test the sequence with representative files before treating it as a 24-hour channel. Check that the Control Room sees the stream, that the picture and sound are present, and that each file boundary behaves as expected. A successful FFmpeg exit is not by itself proof that YouTube is receiving the intended video and audio.
YouTube’s encoder guidance says to test before starting a live stream and to monitor stream health and review messages during the event. Watch the health indicator while representative motion and audio are playing. A channel with a still image can hide a video issue that only appears when a later clip has a different frame size or codec. Check the source transitions, not only the first minute of the first file.
If the ingest reports trouble, work from the edges inward. Confirm the current server URL and key in Live Control Room; confirm SRS is receiving the publishing input; confirm the relay or transcoder output points to YouTube; then compare codec, bitrate, frame rate and keyframe interval with YouTube’s current table. Change one layer at a time so you do not mistake a credential correction for an encoding fix.
Also monitor the publisher process and the machine or hosting environment that runs it. An always-on stream is a chain: files must remain readable, FFmpeg must advance or recover, SRS must stay available if it is in the path, and the final connection must remain usable. A restart policy can help recover a dropped process, but test what happens to the broadcast and playlist position after a restart rather than assuming it resumes at the intended item.
When the test passes, write down the actual command/configuration version, file order, restart behaviour and private location of the stream key. Keep a copy without the key for troubleshooting or future edits. YouTube can change interface labels or encoder recommendations, and SRS syntax is release-sensitive, so check the current official documentation again when you change the software or destination.
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 stream a playlist to YouTube Live?
Use FFmpeg or a script to decide which file plays next, publish the resulting input through SRS if you need SRS in the path, and send the final output to YouTube’s current ingest URL with the key from Live Control Room. Test file boundaries, looping and recovery with the actual media before relying on the sequence unattended.
Can SRS ingest an FFmpeg playlist?
The archived SRS v4 ingest guide says its ingest accepts one input and does not ingest a file list. It recommends a script that uses FFmpeg to publish files one by one; FFmpeg playlist or concat input is a separate approach that you must validate for your files and build.
How do I send an RTMP stream from SRS to YouTube?
Configure the final publishing hop to use the server URL and stream key shown in YouTube Live Control Room. YouTube recommends RTMPS for encrypted ingest, so use the secure URL where available and verify that your SRS/FFmpeg release supports the path you choose.
Do I need to transcode every file?
No. If the source streams are compatible and meet the required output settings, stream copy or remuxing may be sufficient. Re-encode when you need to change codec, resolution, bitrate or other output properties, then check the result in the Control Room.