To loop an MP4 through SRS to YouTube Live, FFmpeg must read and repeat the file, publish that live-paced output to an SRS RTMP endpoint, and SRS must then relay it to the YouTube event destination. The SRS publishing URL is not your YouTube URL or stream key; keep those as separate endpoints and credentials.
The command below is a starting point, not a universal recipe: the file’s codecs, your SRS release and its forwarding configuration all matter. Set up a test event, adapt the relay for your deployed SRS version, then confirm the incoming picture and sound in YouTube Live Control Room before treating the workflow as ready.
Understand the three-part pipeline
Think of the workflow as three connected but distinct jobs. FFmpeg reads the MP4 from your computer or the machine where you run FFmpeg, repeats it, and sends a real-time stream to SRS. SRS accepts that incoming RTMP publish and forwards it to the event destination configured for YouTube. YouTube receives the forwarded stream and reports whether it is healthy in Live Control Room.
The first destination is an SRS application and stream path, for example rtmp://SRS_HOST/live/STREAM_NAME. It identifies where FFmpeg publishes within your SRS deployment. SRS_HOST, live and STREAM_NAME are placeholders; use the address, application and stream name that your own SRS configuration exposes. A localhost address is suitable only when FFmpeg and SRS are on the same machine and that endpoint is configured to accept the publish.
The second destination comes from YouTube Live Control Room: an event’s stream URL and stream key. Those belong in the YouTube-facing relay settings, not in FFmpeg’s SRS input URL. Do not paste a real key into a public example or leave one in a shared terminal transcript. If the key is exposed, use YouTube’s current controls to replace or reset it.
A failure at one stage can look like a failure at another. FFmpeg may run successfully while SRS is not forwarding; SRS may connect while YouTube rejects an unsupported media configuration; or the event may receive a signal but show poor stream health. Check each hand-off rather than treating one running process as proof that the broadcast is ready.
If your goal is a continuous devotional station rather than a one-off test, first decide what the viewer should hear when the file reaches its end. A single MP4 repeated from the beginning creates a noticeable reset unless the edit has a clean join. The practical considerations in planning a Telugu devotional instrumental radio channel are useful when choosing and arranging the content, but the transport steps here remain the same for music, ambience or a local information loop.
Prepare the MP4 and YouTube event
Before starting FFmpeg, inspect the file’s video and audio streams. Confirm that it plays from beginning to end, has the intended aspect ratio and frame rate, and does not contain a silent lead-in or an abrupt final frame that will be repeated every cycle. Check that the sound is present at a sensible level. A file that plays locally is not automatically suitable for every live ingest path.
YouTube’s current encoder guidance lists H.264, H.265 and AV1 video, AAC or MP3 audio, and CBR bitrate encoding. It recommends a two-second keyframe interval and says not to exceed four seconds. The same guidance varies bitrate recommendations by resolution, frame rate and codec, so do not copy one bitrate value into every channel. Choose settings for the resolution and content you actually have, then check the current table before a public broadcast.
For a compatibility-oriented first pass, encoding to H.264 video and AAC audio is a reasonable illustrative approach, as in the command below. It takes more processing than copying already-compatible streams, and the output still needs to suit the complete FFmpeg-to-SRS-to-YouTube path. Stream copy can avoid re-encoding when the input streams and every part of the path support them, but -c copy is not a safe assumption for an arbitrary MP4.
Create or select the YouTube event in Live Control Room and obtain its stream URL and key from the event’s connection settings. The values can vary by event or key configuration; use the values shown for the event you are testing rather than a sample from a tutorial. Keep both values available for the SRS destination setup, but do not include the key in this article’s command or in a screenshot.
YouTube recommends RTMPS, which encrypts the connection to its ingest endpoint. Its RTMPS explanation describes it as RTMP over a TLS/SSL connection. Prefer RTMPS for the SRS-to-YouTube hop when your deployed SRS version and relay configuration support it; confirm the protocol support at both ends rather than assuming that a local RTMP publishing endpoint dictates the protocol used for forwarding.
Loop the input with FFmpeg
FFmpeg’s -stream_loop -1 repeats an input indefinitely. It is an input option, so put it before the -i that names the MP4. The -re option paces file input at its native rate; SRS uses it in its own basic FFmpeg publishing example, and it is important when sending a file as a live stream rather than letting FFmpeg race through it.
Here is an illustrative publishing command:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -tune zerolatency \
-c:a aac -f flv \
rtmp://SRS_HOST/live/STREAM_NAME
Replace input.mp4 with the path to your file and replace the endpoint placeholders with the values exposed by your SRS setup. The FLV output is used for this RTMP publishing pattern. The command re-encodes both tracks; it is not a tested promise that every file, build or machine will produce the desired output. If you adjust resolution, frame rate, bitrate or keyframe interval, base those choices on the file and YouTube’s current encoder guidance, then validate the result end to end.
The command intentionally contains no YouTube key. FFmpeg sends its output to SRS; it does not use the SRS path as a substitute for the event’s destination details. Your SRS configuration supplies the separate forwarding step. This separation also makes it easier to troubleshoot: if FFmpeg reports a publishing error, inspect the SRS host, path and access configuration first; if FFmpeg publishes but YouTube sees nothing, inspect the relay and event destination next.
Do not add -stream_loop -1 after -i and expect it to loop that input: option placement is meaningful in FFmpeg. If the process stops, capture the error and identify whether it stopped opening the file, encoding, or publishing to SRS. A terminal left open overnight is not monitoring by itself. For background operation on a self-managed machine, also decide how you will notice a stopped process and restart it, and what happens after a power or network interruption.
Publish FFmpeg to the SRS endpoint
The SRS documentation’s simple example publishes a file to an RTMP path such as rtmp://localhost/live/livestream. That is an example endpoint for an SRS instance, not a YouTube event URL. The SRS getting-started guide provides context for publishing to SRS; its sample host and stream name should not be mistaken for values that will work on an unrelated deployment.
Use the host reachable from the machine running FFmpeg. If both processes run on one machine, a loopback host may work. If SRS is on another machine, use its reachable address and ensure network access and firewall rules permit the RTMP publish. A private address that only works inside one network will not work from a remote FFmpeg host. Avoid opening a publishing endpoint broadly just to make a quick test; use the access controls and network exposure appropriate to your deployment.
The /live/STREAM_NAME portion is also configuration-dependent. SRS must be listening for the application and accepting the particular stream path you publish. A connection refusal points towards an unreachable host or listener; a rejected publish can instead indicate a path, authentication or configuration mismatch. Read the SRS logs for the receiving instance as well as FFmpeg’s output.
For a small devotional or study channel, the operator’s machine can remain responsible for the file-to-SRS hop if you are comfortable maintaining it. That means power, connectivity, process supervision and access to the SRS host all become part of the overnight plan. If your priority is not leaving a computer running, StreamNeo removes the separate task of keeping a local playback-and-publishing machine on by turning an uploaded video into a YouTube live stream, though this SRS/FFmpeg workflow is for people specifically choosing to operate that chain themselves.
If the video orientation needs adjustment before it becomes a loop, handle that as a media preparation question rather than an SRS setting. The guide to streaming portrait videos in a 16:9 FFmpeg YouTube loop covers that distinct framing problem; keep the resulting output dimensions and encoding choices consistent with the event settings you plan to test.
Configure SRS forwarding for your version
The forwarding step is where a generic copy-and-paste SRS configuration becomes risky. SRS documentation is not one timeless configuration file: the RTMP documentation available for version 5.0 is marked archived, while the current getting-started documentation is in the v8 line. Historical v4 examples can help explain the concept, but they do not establish that a stanza from one release is valid in another.
Start by identifying the exact SRS release you have deployed and consult its documentation for forwarding or relay configuration. Configure that release to take the incoming SRS stream and send it to the YouTube event’s destination URL and stream key, using the transport and media formats supported on the whole path. Do not put YouTube credentials into the FFmpeg-to-SRS publish URL merely because both URLs use RTMP-like syntax.
The division of settings should remain clear:
| Hop | What it does | Values to configure |
|---|---|---|
| FFmpeg to SRS | Publishes the looped file into SRS | SRS host, application, stream name and any required publish access settings |
| SRS to YouTube | Relays the incoming stream to the event | YouTube event URL, stream key, and supported RTMP or RTMPS transport |
This table describes roles, not a ready-to-paste SRS configuration. Follow the syntax and relay behaviour documented for your installed release. If a guide supplies a configuration block, check its version and confirm that its destination field expects the YouTube URL and key in the form you have from Control Room. Never publish a genuine key when asking for help in a forum or sharing a configuration file; redact it first.
YouTube accepts RTMP and RTMPS ingest, but recommends RTMPS. The encryption benefit applies to the connection reaching YouTube; it does not appear simply because the local publishing URL contains rtmp. Confirm that your relay can establish the chosen destination transport, and that the codec and keyframe characteristics survive the relay or are converted as required. SRS’s own documentation and configuration for the release you are using should govern the exact forwarding mechanism.
When choosing between RTMP and RTMPS, the practical trade-off is compatibility versus encrypted transport to YouTube. Use RTMPS if supported by your SRS relay and verify the event receives it. If you must use RTMP for a particular deployment, understand that it does not provide the TLS encryption described for RTMPS and check YouTube’s current guidance before relying on it. Neither protocol choice makes an incompatible codec or a misconfigured key work.
Verify the stream in Live Control Room
Do not treat an FFmpeg process that has printed no error as a validated broadcast. Start with a private or otherwise appropriately limited test event, begin the FFmpeg publish, then confirm that SRS receives the stream and that the configured relay is actually connecting to YouTube. Finally inspect the event in Live Control Room for incoming video, audio and stream health. YouTube’s live streaming help is the place to check current event and monitoring procedures.
Look for a stable picture, expected aspect ratio, audible sound, and a clean transition when the MP4 reaches its end and loops. Pay attention to the specific media and motion in your file: a static devotional image with gentle music exercises a different part of the path than a news loop with frequent movement or embedded text. YouTube recommends testing with representative audio and motion and monitoring stream health; use the actual material, not an empty slate, as your test.
If Control Room does not show an incoming signal, verify the chain in order: FFmpeg opened the correct file and is publishing to the intended SRS path; SRS accepted that stream; the version-specific relay is enabled and points to the event URL and key; and the destination transport is supported. If video arrives without sound or health warnings appear, check the audio stream, output codec, bitrate and keyframe interval against YouTube’s current recommendations. Avoid changing several variables at once, because that makes the cause harder to identify.
Keep the test running long enough to see the loop boundary and confirm that the source does not stop after one pass. A successful short connection only proves that the chain connected at that moment. Before a real overnight run, test the conditions you can: source file access, network stability, SRS restart behaviour, FFmpeg restart or supervision, and whether you can see an alert or status when the relay drops. No configuration can remove the need to watch the actual event’s health.
For bandwidth symptoms, distinguish the incoming source from the path between your publishing machine, SRS and YouTube. A fast speed-test result does not rule out loss or jitter on the active route; the packet loss and jitter checklist can help you investigate that separate issue without changing an otherwise sound loop command.
Decide how you will operate it overnight
A self-hosted chain gives you direct control over the source file, encoding and SRS relay, but you also own the moving parts. The machine running FFmpeg needs power and access to the file; the SRS instance needs to remain reachable; and the relay must continue to deliver the event stream. Plan who will notice a failed process, how it will be restarted and how you will recheck Control Room after recovery. A process that restarts locally may still need the YouTube connection to recover cleanly.
Write down the working values without exposing secrets: SRS release, input file name, local publish path, output media settings, destination transport and where the event key is managed. Store the actual key only in a suitably restricted configuration or secret store for your setup, not a shared document, public repository or screenshot. The YouTube sources establish where the event URL and key are obtained and describe RTMPS encryption; careful handling of credentials is a practical security measure alongside that guidance.
Do one final check on the event itself before moving from test to public operation. Reconfirm that the selected event is the intended one, that its stream key corresponds to that event configuration, and that Control Room reports a healthy incoming stream. For a playlist-like channel with multiple videos, compare the content and loop behaviour with using a YouTube playlist as a 24/7 livestream source; a playlist and a single repeated MP4 are different ways to organise what viewers see, even though both need a dependable live path.
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 loop an MP4 video on YouTube Live with FFmpeg?
Use -stream_loop -1 before the input’s -i option, and use -re to send the file at real-time pace. Publish FFmpeg’s output to your SRS endpoint, then configure SRS separately to relay it to the YouTube event URL and key. Confirm the resulting stream in Live Control Room.
Is the SRS RTMP URL the same as the YouTube stream URL?
No. The SRS URL is where FFmpeg publishes into your own SRS application and stream path. The YouTube event URL and stream key are a separate destination configured for SRS forwarding, and the key should not be included in a public example.
Can I copy the SRS forwarding configuration from another version?
Do not assume it will work unchanged. SRS documentation and configuration syntax vary by release, so identify your deployed version and use its corresponding documentation before setting the relay destination. Validate the complete path in Control Room.
Should I use RTMP or RTMPS for YouTube?
YouTube supports RTMP and RTMPS ingest and recommends RTMPS. Use it when your SRS relay supports the transport, then verify that it connects and that the chosen media settings are accepted. RTMPS encrypts the connection to YouTube; it does not guarantee stream health or compatibility.