FFmpeg can play and encode a playlist for YouTube Live without NGINX. NGINX RTMP is an optional stage: you can use it to receive an FFmpeg feed locally or relay a feed onward, but it does not create the playlist or replace YouTube’s stream credentials.
For a dependable 24/7 channel, first choose the signal path, then test the chosen NGINX implementation, media files and FFmpeg build together. There is no universally valid playlist-loop command: file formats, timestamps, audio, and FFmpeg versions affect what will work.
Understand the components and signal path
Think of the setup as three separate jobs. FFmpeg reads your media, schedules playback and produces the encoded audio and video. YouTube Live accepts that finished feed at an ingest address using a private stream key. NGINX with an RTMP module can optionally sit between FFmpeg and YouTube as an ingest point or relay.
The simplest path is FFmpeg directly to YouTube. FFmpeg reads the media and sends its output to YouTube’s server URL with the stream key. NGINX is not part of that connection. This is a sensible starting point if you have one encoder process and do not need a separate RTMP endpoint.
A relay path is FFmpeg to NGINX to YouTube. In that design, FFmpeg publishes to an RTMP application configured in NGINX, and NGINX forwards the accepted stream to YouTube. This adds a process and a configuration boundary. It can be useful when the sender and relay are separate, or when your setup specifically needs a local or remote RTMP ingest stage, but it also gives you another process to test and monitor.
Do not confuse an RTMP module with NGINX’s HTTP HLS module. The third-party RTMP module has its own live and HLS-related directives. The NGINX HTTP HLS module documentation describes a different feature for serving HLS from supported media files. It is not a substitute for configuring an RTMP relay.
Before configuring anything, draw the path and label each endpoint: source files, FFmpeg output, optional NGINX input and output, and YouTube ingest. That small diagram helps you identify which log or preview to inspect when a feed stops. If the aim is a scheduled rotation rather than a single repeated file, planning the order and transitions first is useful; see this guide to a daily playlist rotation.
Create a YouTube Live stream
In YouTube Studio, create or select a live stream and open the Live Control Room. Copy the ingest server URL and stream key shown there into the final encoder configuration. YouTube describes the key as a password/address that allows the encoder to send a feed, so treat it as a credential: do not paste it into a public script repository, screenshot, or support post. If it is exposed, replace it in Studio before broadcasting again.
YouTube’s encoder setup guidance covers connecting an encoder to a live stream. Prefer the RTMPS ingest URL when the encoder supports it. YouTube recommends RTMPS as the encrypted extension of RTMP in its RTMPS guidance. If your chosen relay or FFmpeg build cannot connect over RTMPS, check the current YouTube instructions and the capabilities of the exact software build rather than assuming a URL scheme will work.
Keep the stream key out of command examples that will be shared. A practical approach is to put credentials in a private configuration file or environment-specific setting with access limited to the operator account, and to redact them from logs before sharing diagnostic output. Check where your shell history and process listings may expose command-line arguments. The exact exposure risks depend on the operating system and deployment, so verify how your environment handles them.
A stream can be created and tested before it is publicly promoted. Confirm the selected privacy and scheduling settings in Studio, then send a test feed and wait for the preview and stream-health information to appear. Keep the Live Control Room open during initial checks; a successful process launch on your machine only confirms that the process started, not that YouTube is receiving a valid picture and sound.
Choose direct publishing or an NGINX relay
Pick the least complicated path that meets your operational needs. Direct publishing gives you one sending process and one destination. A relay adds a place to ingest and forward, which can help with a deliberate topology but means you must configure and observe both the sender and relay. Neither path is inherently more reliable without testing and restart arrangements.
| Path | What connects to what | Useful when | Main trade-off |
|---|---|---|---|
| Direct | FFmpeg → YouTube | One sender can reach YouTube and no intermediate RTMP endpoint is needed | FFmpeg owns playback, encoding and the outbound connection |
| Relay | FFmpeg → NGINX RTMP → YouTube | You need an RTMP ingest or relay stage in the chosen design | More configuration, credentials and processes to validate |
Start direct if you are learning the media and YouTube portions of the workflow. Add NGINX only when you can state what it will do for you. A relay is not a way to make an invalid playlist command work, and it does not remove the need to check output encoding, network capacity or YouTube stream health.
There is a separate choice between copying compatible streams and transcoding. Stream copy can avoid re-encoding, but only when the inputs already have compatible video and audio codecs, frame properties, timestamps and other characteristics for the intended output. Transcoding lets FFmpeg convert inputs to a consistent output, but uses CPU or other available encoding resources and can introduce overload if the machine is not sized and tested for the workload. Do not assume that mixed files can be joined cleanly just because each plays on its own.
For a channel built around episodes or spoken segments, think through whether the output should be one continuous broadcast or a succession of separate sessions. The continuous podcast broadcast guide can help clarify the editorial and operational consequences of combining material. The choice also affects archive handling, discussed below.
Select the relevant NGINX RTMP implementation
“NGINX RTMP” does not name a single interchangeable package. One path is the NGINX Plus RTMP dynamic module documented by F5 NGINX. Another is the third-party arut/nginx-rtmp-module project. Their installation, compatibility and configuration paths differ. Choose one implementation deliberately and follow its own documentation for your operating system and NGINX build.
The NGINX Plus dynamic-module guide documents a Plus-specific package and module-loading path. It includes loading ngx_rtmp_module.so, checking the configuration with nginx -t, and reloading NGINX. Those instructions are not generic installation steps for every community NGINX package or a source build. Confirm that the module matches the NGINX version and package you actually run.
The arut module is a separate project with its own build and directives. Its README and the module’s directive documentation are the place to check the syntax supported by the build you chose. Avoid copying a configuration from another implementation and assuming that its application blocks, options or build process will behave identically. A configuration accepted by one binary may not be available in another.
If your design uses NGINX as an RTMP relay, configure an RTMP application that accepts the FFmpeg publisher and define how that feed is forwarded to YouTube. Keep the YouTube destination and key private. Before starting a live test, validate the syntax using the appropriate command for that installation; for the Plus dynamic-module path, the official guide specifically calls out nginx -t before reload. Then check the NGINX error log and confirm that the relay receives and forwards the stream.
Do not add HTTP HLS directives simply because a guide mentions “HLS” alongside RTMP. The third-party module’s HLS functionality and NGINX’s separate HTTP HLS module are distinct things with separate requirements. If serving HLS is part of your design, verify the selected module’s documentation and licence or subscription conditions directly before building around it.
Configure and test FFmpeg playback
Prepare a representative sample playlist before you target a full-day schedule. Include the kinds of files that will really run: different durations, resolutions, frame rates, codecs, audio tracks and any still images or silent sections. Check that each item decodes, that the intended order is correct, and that audio does not disappear or jump unexpectedly at transitions.
The research for this guide did not establish a canonical FFmpeg loop command for arbitrary playlists. Do not treat -stream_loop, a concat recipe or a shell loop as universal. Validate the exact command against your installed FFmpeg version and actual media. A command that works for one file may not preserve timestamps or transition cleanly across a mixed playlist; a process that exits after one pass will not keep a 24/7 channel running.
Build the test in stages. First play each file locally and inspect the output. Then send a short representative feed to YouTube, initially using either the direct path or your configured relay. Check that motion and audio are both present, that the preview remains current, and that the health panel reports no unresolved issue. Only after those checks should you test a longer rotation that includes the end-to-start boundary.
Choose output settings with both YouTube’s recommendations and your sustained upload capacity in mind. YouTube’s current encoder settings and bitrate guidance lists H.264, H.265/HEVC and AV1, recommends constant bitrate, and recommends a two-second keyframe interval that should not exceed four seconds. For H.264, its table gives 5 Mbps as the recommended bitrate for 1080p at 30 fps, and 8 Mbps for 720p at 60 fps. These are YouTube recommendations, not a promise that your uplink can sustain them. Select a compatible setting, leave room for network variation, and test the actual outbound feed.
RTMPS protects the connection in transit when supported, but it does not fix weak upload capacity or an overloaded encoder. Likewise, choosing a lower resolution can reduce the bitrate requirement but may not suit the material or audience. Use the same resolution, frame rate, audio arrangement and encoding method in your test that you intend to keep for the live channel.
Validate continuity and restart behaviour
A 24/7 service needs a plan for more than the happy path. Confirm what happens when a file ends, a playlist reaches its final item, FFmpeg exits, NGINX restarts, the network drops, or the machine reboots. Your chosen playlist mechanism must actually continue through the intended rotation, and the sender must reconnect or be restarted according to a method you have tested. Do not assume that one process automatically recovers merely because it can be started from a terminal.
Decide how you will detect failure. At minimum, someone should know how to check the FFmpeg process, NGINX status and logs, the upload connection, and YouTube’s preview and stream-health messages. For unattended operation, configure and test a supervisor or other restart mechanism suitable for your operating system and deployment. Verify the behaviour by deliberately stopping the relevant process during a controlled test, then confirm that it restarts, reconnects and restores audio and video. The exact mechanism is deployment-specific; a restart policy is not useful if it repeatedly launches a broken command or hides a credential/configuration error.
Watch local resource and output signals during a longer rehearsal. Check that disk space remains available for logs or recordings, CPU or hardware encoding stays within the machine’s capacity, and the network connection can sustain the selected stream. If you encode continuously on a local PC, measuring its actual draw helps estimate the cost of leaving it on; see how to measure a PC’s power draw for a 24/7 stream. Treat measurements from your own machine and tariff as more relevant than assumptions based on hardware labels.
Plan archives separately from the live feed. YouTube says that streams under 12 hours can be automatically archived, while a stream exceeding 12 hours may not be captured at all. A single continuous 24/7 broadcast therefore is not a dependable complete archive. If you need to retain the full programme, arrange an independent recording or split the schedule into shorter sessions, then verify that the expected recordings are actually available. Check YouTube’s current archive guidance before relying on platform behaviour.
A cloud-based route can remove the need to keep your own computer running for the broadcast: StreamNeo takes an uploaded video and runs it as a YouTube live stream after you provide the stream key, so the specific burden of leaving a local playback machine on is removed. That does not settle playlist compatibility or archive planning, which still need to be checked for your channel.
Put the test into an operating checklist
Before launch, write down the files and their order, the FFmpeg version, the tested playback and encoding configuration, the chosen NGINX implementation if any, and where each log is found. Keep a private copy of the stream settings and a procedure for rotating the key if it leaks. This record makes a later change easier to diagnose: if an FFmpeg upgrade, media replacement or module update alters the result, you know what changed.
Use a pre-publication checklist that another operator could follow. Confirm the correct YouTube event and key, test the playlist from its beginning and across a transition, check picture and sound in the preview, inspect the health messages, and verify the restart path. If you operate more than one channel, label each configuration clearly so one channel cannot accidentally publish to another channel’s ingest endpoint.
If a stream fails, isolate the layer rather than changing several things at once. Check whether FFmpeg is still reading and encoding, whether NGINX is accepting and forwarding (if used), whether the network can reach the ingest endpoint, and whether YouTube reports the incoming feed. A short diagnostic test with one known-good media file can distinguish a playlist problem from a relay or credential problem. Once the cause is clear, repeat the longer continuity test before treating the service as ready.
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 YouTube require NGINX RTMP for a 24/7 playlist?
No. You can have FFmpeg publish directly to YouTube using the ingest URL and stream key from Live Control Room. NGINX with an RTMP module is optional and makes sense only when your design needs an ingest or relay stage.
How do I loop a playlist on YouTube Live?
FFmpeg must keep reading the intended media in order and produce a continuous compatible output, but a loop command is not universal for arbitrary files or FFmpeg versions. Test the exact command with your actual media, including timestamps, audio and the transition from the final item back to the first, before relying on it unattended.
Where should I put the YouTube stream key?
Use the key with the final encoder’s YouTube destination, whether FFmpeg publishes directly or NGINX forwards the feed. Keep it private and out of public scripts or support messages; reset it in YouTube Studio if it is exposed.
Does YouTube archive a 24/7 live stream?
Do not rely on one continuous 24/7 stream as a complete YouTube archive. YouTube says streams over 12 hours may not be captured at all, so make independent recordings or use shorter sessions if retaining the programme matters, and verify the resulting archives.