To rotate a folder of videos in an NGINX RTMP YouTube stream, use a playlist-capable media process to choose and play the files, then send its continuous output to YouTube, directly or through NGINX RTMP. NGINX RTMP can handle live streams, relay feeds and provide documented VOD playback, but you should not assume its play directive will turn an arbitrary folder into a repeating playlist.
The dependable part of the setup is the separation of jobs: decide the order and repeat policy, check that the media can be joined cleanly, and test what happens at file boundaries and after a disconnect. The precise playlist mechanism depends on your operating system, media and installed tools, so verify it on your own setup rather than relying on a universal command.
Define the folder rotation workflow
A folder is a place to store files, not a playback policy. To make a stream rotate through it, something must identify which files to play, in what order, whether to repeat them, and what to do if one is missing or unreadable. A simple library might play morning.mp4, prayer.mp4 and evening.mp4 in that order, then start again. The order should be explicit, not left to whichever order a file browser happens to show.
The workflow has three jobs. First, a playlist or script selects files and defines the sequence. Second, a media process reads them and emits a stream suitable for continuous playback. Third, a publishing endpoint sends that stream to YouTube Live. NGINX RTMP can be part of that last job, but it does not replace the first two.
Decide early whether the folder is static or expected to change while you are live. For a small, rarely updated library, a fixed playlist is often easier to inspect: you know what will play next and can test the exact order. If files are added during the day, specify whether they join the current cycle or take effect only after a restart. The reviewed module documentation does not establish dynamic folder-watching behaviour, so that part must be supplied and tested by your playlist mechanism.
Also decide what a failure should mean. If a file is corrupt, should the process skip it and continue, stop for an operator, or retry? There is no safe assumption that every playlist tool handles errors in the same way. Test a missing-file case before relying on an unattended channel. For other playlist approaches, the practical distinction between a player and the relay is also useful in an OBS and VLC playlist workflow.
Separate NGINX RTMP playback from relay
The NGINX RTMP module has several roles that can sound similar when described simply as “playing video”. Its documented VOD feature serves local filesystem or HTTP video playback for FLV and MP4. The README also documents external program execution and pushing streams to remote RTMP destinations. These are useful capabilities, but the reviewed documentation does not promise that pointing playback at a directory creates a continually rotating playlist.
For a folder rotation, treat NGINX as a receiver or relay if that fits your design. The playlist-capable process reads the files and produces the live feed; NGINX can receive that feed and push it onwards. Alternatively, the module’s external-program feature can be used to invoke another process. That is a way to connect components, not proof that a particular FFmpeg invocation will work on every build or operating system.
The distinction matters when troubleshooting. If NGINX accepts a connection but the stream ends at the first file boundary, inspect the playlist and media process. If that process continues but YouTube loses the broadcast, inspect the output connection, destination settings and stream health. A relay can forward media; it cannot infer your desired file order or repair incompatible source files simply because they are stored together.
The nginx-rtmp-module README documents the module features and caveats. Check that the RTMP module is actually present in your installed NGINX build, because installation paths differ between the community module and NGINX Plus. The README also notes limited Windows support and that exec is unsupported there; do not assume a Linux-oriented external-process configuration applies to a Windows build.
Build an ordered playlist from the files
Start with an inventory. Record each filename, its intended position, whether it has audio, and any known differences in frame size or frame rate. Use a written playlist or a script that produces an explicit order. Avoid relying on a wildcard or directory listing unless you have checked how that particular tool sorts names and handles spaces, punctuation and non-English characters.
A static list is a reasonable first test when the library rarely changes. It makes the rotation auditable: you can compare the intended sequence with the actual output and spot a skipped or repeated entry. If the folder changes while broadcasting, plan how the playlist is refreshed. Some implementations read a list once at startup; others can watch for changes, but the latter behaviour is implementation-specific. Do not claim that new files will appear without restarting until you have tested that exact arrangement.
Keep source files in a stable location and avoid renaming or moving them while the process is running. If the media process opens a file only when its turn arrives, a changed path can break playback later rather than immediately. A preflight check can confirm every listed path exists and is readable before you start. For a channel run by several people, keep the playlist and file naming conventions simple enough that another person can see what will play next.
A playlist is not necessarily a single continuous media file. The player must transition between entries, and its output must remain acceptable to the receiver. This is why a playlist-capable player or FFmpeg-based process belongs in the design, even if NGINX handles the RTMP connection. A related distinction appears in the GStreamer pipeline example for a 24/7 news channel: the media pipeline constructs playback while the publishing path carries it to the platform.
Use a media process to play and repeat the list
Use a process that explicitly supports playlist input and repeat behaviour. FFmpeg can be part of such a workflow, but the exact input syntax and loop semantics depend on the chosen playlist format, FFmpeg version, operating system and media. A command copied without checking those details may exit at end-of-file, repeat the wrong item, or fail on a filename. Treat examples you find elsewhere as starting points to test, not as guarantees of an endless loop.
There are two broad ways to connect the media process to NGINX RTMP. You can run the publisher separately and have it send a feed to an NGINX application, or configure NGINX’s external-program support to launch a process in response to a stream event. The first makes the player and relay easier to start and inspect independently. The second can tie process launch to the NGINX configuration, but it adds operating-system and process-supervision considerations. Neither arrangement automatically gives you robust error recovery or folder updates.
| Design choice | Useful when | What you need to test |
|---|---|---|
| Separate playlist publisher, NGINX receives or relays | You want to start and troubleshoot playback independently from the relay | Publisher restarts, destination reconnection, and whether NGINX receives one continuous feed |
| NGINX external program starts the media process | You want process launch linked to an NGINX stream event | Build support, operating-system support, process exit behaviour, and how a failed file affects the stream |
| Static playlist | The library and order rarely change | End-of-list repeat behaviour, missing files, and transitions between unlike media |
| Folder that changes during playback | New material must join without a planned restart | When changes are noticed, ordering, duplicate handling, and what happens to the current cycle |
This is an architectural comparison, not a tested recipe. Before using either design for a live channel, verify the local NGINX configuration and the exact process behaviour. Where appropriate, nginx -t checks configuration syntax, but it does not confirm that FFmpeg can read your media or that YouTube will accept the output. F5’s NGINX RTMP documentation concerns the NGINX Plus dynamic module; do not generalise its installation instructions to every community build.
If the recurring burden is keeping a playback computer running, StreamNeo removes that specific requirement by taking an uploaded video and running it as a YouTube live stream with your computer switched off. It is YouTube-only, so it does not replace a custom NGINX playlist pipeline when you need that architecture or need files to rotate dynamically from a local folder.
Publish the resulting stream to YouTube
YouTube Live provides the server URL and stream key in Live Control Room. Put those values into the publishing encoder or the relevant relay destination, and treat the key like a password. Do not paste it into a public configuration sample, screen recording or support post. YouTube explains stream setup in Manage live stream settings; consult the current page for the controls available to your account.
If NGINX receives a feed from the media process, confirm the application name and stream path agree on both sides. The module README shows an RTMP URL shaped like rtmp://host/app/name, where app corresponds to an application block. That is a path convention, not a complete configuration for your machine. Check your module’s documentation and the actual configuration before opening the public broadcast.
YouTube’s current encoder guidance covers H.264, H.265/HEVC or AV1 video; frame rates up to 60 fps; AAC or MP3 audio; and constant bitrate encoding. It recommends a two-second keyframe interval and says it should not exceed four seconds. These are platform settings, not a guarantee that a particular source file or encoder will behave well. Confirm supported codecs and the destination URL in the current Live Control Room before publishing.
YouTube recommends RTMPS when supported. Its encoder settings and bitrate guidance explains the current recommendations and bitrate tables. Use the RTMPS address supplied for your stream rather than assuming an RTMP URL can simply be changed by adding an “s”. Keep the key private, and reset it through Live Control Room if it is exposed.
Check media compatibility and transitions
Files that look alike to a viewer may differ technically. Check the video codec, dimensions, frame rate, aspect ratio, audio codec, sample rate and channel layout for representative files. If these characteristics differ, passing each file through unchanged may not produce a consistent output. Stream-copying can be insufficient; encoding or normalisation may be needed. Decide this from inspection and test playback, not from the file extensions alone.
Pay particular attention to audio. One clip may have stereo sound, another mono, and another no audio track. A media process may handle those cases differently at a boundary, leaving silence, a click or an output-format change. Listen across transitions with headphones and check that dialogue, music and ambience do not jump unexpectedly. If your channel is devotional or a study station, a small gap between tracks can matter more than a visually clean cut.
Check aspect ratio and framing as well. A portrait clip mixed into landscape content may appear with bars, be cropped, or force a change in the output dimensions depending on the chosen process. If you need a fixed canvas, decide whether to pad or crop before encoding and check the result on a phone-sized display as well as a desktop preview. The relevant trade-off is preserving the whole picture versus filling the frame, as explored in this guide to cropping portrait videos for a playlist stream.
Test the end of one file and beginning of the next, not only the middle of each clip. Look for a pause, frozen frame, audio discontinuity or abrupt format change. Then let the list pass its final entry and verify that the repeat behaviour starts where you expect. A loop that works for two similar files may fail when the final file has a different audio layout or frame rate. Use representative material from the whole folder, especially the files most unlike the rest.
Test reconnects and long-running behaviour
Begin with a private or otherwise controlled test, not a public 24/7 launch. YouTube recommends testing with representative movement and audio and monitoring stream health. Watch both the local media process and Live Control Room while a file changes. Confirm that the stream remains connected at the boundary and that the health indicators do not report a codec or network problem.
Test a deliberate publisher interruption. Stop the media process, then restart it and observe whether the relay reconnects and whether YouTube treats the result as the same live session or a new interruption. Repeat the test with the relay side if your architecture has one. The outcome depends on process supervision, connection timeouts and the platform session; do not infer restart behaviour from a successful initial connection.
For an unattended channel, decide who notices a failure and what action they can take. A log or alert is useful only if someone knows what to check: playlist path, file read error, encoder exit, NGINX connection, or YouTube stream health. Test at least a missing file and a temporary network loss. If the playlist stops at a bad entry, establish whether it skips, retries or requires manual intervention before leaving the system alone overnight.
A computer-based arrangement also depends on the host staying awake, the network remaining available and the process continuing to run. If you use a remote host, test its restart and maintenance behaviour rather than assuming a shell session keeps a broadcast alive. If your main issue is a stream that should loop but ends, the troubleshooting guide for a podcast live stream that is not looping may help separate a playback problem from a publishing disconnect.
The aim is not to prove that a setup can never fail. It is to know how it fails, how you will see the failure and how to recover without exposing the stream key or accidentally starting a second broadcast. Keep a written runbook with the start order, the expected first file, the control-room check and the recovery steps. Update it when you change the playlist mechanism, NGINX build or encoder settings.
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
Can NGINX RTMP rotate every video in a folder by itself?
Do not assume so. The documented VOD feature covers local filesystem or HTTP playback for FLV and MP4, but the reviewed README does not promise arbitrary directory rotation as a repeating playlist. Use a playlist-capable process to set order and repeat behaviour, then use NGINX as a receiver or relay if it suits your setup.
Is there one FFmpeg command that guarantees an endless folder loop?
No universal command can be promised for every FFmpeg version, playlist format, operating system and set of files. Check the exact loop behaviour, filenames, media compatibility and end-of-file transitions on your own system. Include a missing-file test before relying on the process unattended.
Can I add files while the stream is running?
That depends on the playlist mechanism. A static playlist may be read only at startup, while another tool may support updates; the NGINX RTMP documentation does not settle that behaviour. Test when additions become visible, how they are ordered, and whether a restart affects the live session.
What should I check before sending the stream to YouTube?
Use the server URL and stream key from Live Control Room, protect the key, and confirm the current encoder guidance for codec, audio, frame rate, keyframes and transport. Test a representative clip and a file transition while watching YouTube stream health. If you alter the NGINX configuration, validate it with the appropriate check for your installed build.