NGINX RTMP on Ubuntu 22.04 is one part of a YouTube loop-stream setup, not the component that plays and repeats your video. The NGINX RTMP module accepts or relays streams; FFmpeg reads your local media and publishes the outgoing audio and video to YouTube.
The module’s project documentation describes building it with NGINX and gives configuration and FFmpeg examples. It does not establish a current, tested Ubuntu 22.04 command for looping indefinitely. Treat installation, media playback, publishing and recovery as separate steps, and test your own combination before relying on it overnight.
Understand the two-stage media pipeline
Think of the setup as a source, an encoder and, optionally, an RTMP relay. Your source is a video or playlist on disk. FFmpeg reads that media, prepares the audio and video for a live broadcast, and sends the resulting stream to an endpoint. NGINX with the third-party nginx-rtmp-module can accept an incoming RTMP stream or relay one onward. It is not a media-file player or encoder simply because it has RTMP in its name.
A direct path is: local media → FFmpeg → YouTube ingest. In that arrangement, NGINX may not be needed at all. An intermediate path is: local media → FFmpeg → your NGINX RTMP application → YouTube ingest. That can be useful when you need a local ingest point or a relay, but adds another configuration and failure point. Use the simpler path unless you have a reason to insert NGINX.
The module’s upstream README documents FFmpeg integration and examples, including an application that accepts a live stream and a push directive for relaying. Those examples explain the roles; they are not a guarantee that every directive is suitable for an internet-facing server. The project’s phrase “Online transcoding with FFmpeg” describes FFmpeg’s role, not a claim that NGINX itself encodes your file. See the module’s README and examples before adapting a configuration.
If your main aim is an unattended recorded lesson or devotional playlist, decide first whether you truly need a server relay. A machine running FFmpeg already needs to stay available unless you move that job elsewhere. Our guide to choosing a low-power computer for a 24/7 lesson stream covers the practical trade-off between leaving a local device on and using another hosting arrangement.
Choose an installation route before building
There are three different ideas that are easy to conflate: an Ubuntu distribution package, a dynamic module supplied for NGINX Plus, and building the open-source module into NGINX from source. The research for this guide does not establish a currently supported open-source Ubuntu 22.04 package name or a tested contemporary NGINX-and-module combination. Do not copy an old package command from a forum and assume it still matches your installed NGINX.
The upstream project documents the source-build approach: obtain NGINX source and module source, configure NGINX with --add-module=/path/to/nginx-rtmp-module, then build and install. That is a documented integration method, not a tested, ready-made recipe for every Jammy system. The version-pinned Ubuntu 22.04.1 community wiki page found in research is old; it is evidence that a source build was once described for that release, not current compatibility validation.
NGINX’s dynamic RTMP module instructions are specifically for NGINX Plus. They describe installing nginx-plus-module-rtmp, enabling it with a top-level load_module directive, checking configuration with nginx -t and reloading NGINX. That page is useful if you run the product it documents, but it should not be presented as the installation path for open-source NGINX on Ubuntu. Check the NGINX Plus module documentation and the product scope before following it.
For a source build, match the NGINX and module revisions deliberately. If replacing an existing NGINX binary, record the current version and its configure options first: a new build with different options can omit capabilities you rely on. Keep the source tree, build notes and configuration changes together so you can reproduce or roll back the installation. This is operational advice, not a claim that a particular build has been tested here.
If you would rather avoid maintaining a local always-on machine, compare the operational choices in our article on Linux VPS costs for continuous YouTube streaming. A hosted machine still requires you to manage the encoder, credentials and recovery; moving the computer does not remove those responsibilities.
Install the build prerequisites
A source build needs a compiler and the development dependencies required by the NGINX options you choose. The exact packages depend on the NGINX release, module revision and enabled features. The available research does not validate a current Ubuntu 22.04 dependency command, so this guide does not provide a copy-and-paste apt install line that could be wrong for your selected versions.
Before installing anything, choose the NGINX release and module revision you intend to build, then consult their current build instructions. Check whether your build needs SSL, compression, or other libraries, and whether Ubuntu’s development packages correspond to them. Install only what the configure options require. Record package names and versions, as well as the source revisions, so a later rebuild does not depend on memory.
Separate the build environment from the live configuration where practical. Compile and inspect the candidate binary before replacing a working installation. If this is a remote machine, keep an existing administrative session available and make sure you know how to restore the prior binary or package. A build that succeeds is not yet proof that NGINX will start with your configuration or that FFmpeg can reach the intended endpoint.
The build process can also affect an existing setup. NGINX features such as TLS support or modules may depend on configure-time options. Preserve the original configuration and inspect the output of the existing binary’s version/configuration report before rebuilding. Include any required options in the new configuration step rather than assuming a source build inherits settings from a package installation.
Build NGINX with nginx-rtmp-module
The upstream module documents adding its source directory to NGINX’s configure invocation with --add-module=/path/to/nginx-rtmp-module, followed by make and make install. At a high level, your working tree contains the selected NGINX source and the selected module source; configure points at the module; compilation produces an NGINX binary with the module integrated. Follow the current upstream README for the exact commands and prerequisites for the versions you select.
The command shape is not a version compatibility guarantee. Do not assume that an arbitrary NGINX source release and the latest module branch will build together, or that build flags from a separate Ubuntu tutorial remain appropriate. Verify that the module revision and NGINX source revision are intended to work together, and retain the configure output and build logs. If the build fails, resolve the mismatch or missing dependency rather than skipping configure checks.
A source-integrated module differs from a separately loaded dynamic module. With the former, the build includes the module in the binary. With a dynamic module, NGINX loads a separately built shared object using a load_module directive, and the binary/module compatibility matters. The NGINX Plus guide demonstrates the latter for NGINX Plus; do not transfer its package name or assumptions to open-source Ubuntu NGINX.
After installation, identify which executable is actually being run and where it reads configuration from. Systems can have more than one NGINX binary or configuration path after a manual installation. Check the binary version, its compiled options and the service definition before editing files or restarting a service. If you keep both a package-managed and source-built copy, make that distinction explicit in your notes to prevent later maintenance from targeting the wrong one.
Check the module and application configuration
The module README’s sample puts an rtmp {} block at the top level of the NGINX configuration. Inside it, the example declares an RTMP server listening on port 1935 and an application with live on;. These are configuration concepts from the project documentation. They do not mean you should expose a public publish endpoint without access controls, nor do they prove that the resulting configuration suits your deployment.
For a local test, start with the narrowest arrangement that lets the intended publisher connect. Decide whether FFmpeg will publish directly to YouTube or to a named NGINX application first. If FFmpeg publishes to NGINX, its output URL must match the host, port, application and stream name that NGINX accepts. If NGINX relays onward, document where the relay is configured and how you will tell whether a failure is at the local ingest or the YouTube destination.
Validate the effective configuration with the nginx -t check appropriate to the binary and configuration path you installed. Do not reload or restart a production service until validation passes. Then confirm the running process uses that configuration and is listening where expected. A syntactically valid file does not establish that an external firewall allows the traffic or that the publisher has permission to publish.
Protect publishing access. Restrict who can reach an ingest endpoint, avoid leaving a broadly accessible live on application, and do not put credentials in a public repository or screenshot. Your YouTube stream key is password-like. If it is exposed, use Live Control Room’s key management to reset it and update the encoder. Keep credentials out of shell history where possible and limit access to any configuration file that must contain them.
Use FFmpeg to read and publish local media
FFmpeg is the component that opens the video file, handles its audio and video streams, and publishes an encoded or suitable copied stream. NGINX RTMP can sit between FFmpeg and YouTube as an ingest or relay layer, but it does not make an ordinary video file repeat itself. The module README’s FFmpeg examples show how the tools can be connected; the research gathered for this article did not verify a current command that loops a file indefinitely on Ubuntu 22.04.
That evidence limit matters for unattended use. An endless loop has to handle more than reopening a file: timestamps must remain acceptable at the join, audio and video must stay aligned, and the publisher must respond to a broken connection. A command that appears to repeat in a short manual test is not evidence that it will continue cleanly through a long run or recover after network interruption. Test the exact FFmpeg version and media file you plan to use.
Start by inspecting the file’s streams and properties, then choose whether you can copy compatible audio/video or need to encode. Copying can reduce work for the machine, but only if the source format and settings are acceptable to the destination. Encoding gives you control over output settings but uses compute and requires sustained upload capacity. There is no server-sizing result in the research here, so test on the actual host rather than inferring CPU or memory needs from a bitrate table.
YouTube’s current encoder guidance supports H.264, H.265/HEVC or AV1 video, AAC or MP3 audio, and frame rates up to 60 fps. It recommends constant bitrate, a two-second keyframe interval that should not exceed four seconds, and for stereo audio a 44.1 kHz sample rate with 128 Kbps audio bitrate. For SDR it also lists guidance such as progressive scan and Rec. 709. Treat these as YouTube’s settings guidance, not a guarantee that a particular FFmpeg build or source file will behave as intended.
| Example output profile | YouTube H.264 bitrate guidance |
|---|---|
| 720p at 30 fps | 3 Mbps minimum; 8 Mbps recommended |
| 1080p at 30 fps | 5 Mbps minimum; 14 Mbps recommended |
| 1080p at 60 fps | 6 Mbps minimum; 17 Mbps recommended |
These figures are YouTube’s published guidance, accessed in 2026, not independent performance measurements. Choose an output profile that fits the source and the sustained upload connection. A higher target can be a poor choice if the connection cannot maintain it; a lower resolution may make a long-running broadcast more dependable in practice. YouTube recommends testing and checking upload capacity rather than assuming the nominal broadband plan describes real sustained throughput. See YouTube’s encoder settings guidance.
Before relying on a loop, verify the join: watch and listen across the boundary, check that timestamps are accepted, and confirm YouTube’s preview remains stable. Then test what happens if the network drops or FFmpeg exits. A process supervisor may restart an encoder, but restarting a process is not the same as ensuring the stream resumes correctly. The research does not establish a tested restart policy or recovery command.
Add YouTube’s URL and stream key
YouTube provides the ingest server URL and stream key in Live Control Room. Create or open the live stream, find the encoder connection details, and enter the server URL and key in the publishing tool. Keep the key private: YouTube explains that stream keys act like passwords and channel owners or managers can reset a compromised one. The steps and labels in the control room can change, so follow YouTube’s official encoder setup instructions at the time you configure the stream.
YouTube recommends RTMPS, which is RTMP carried over TLS/SSL. Use the RTMPS URL supplied in Live Control Room where your publishing stack supports it. Do not assume that a particular combination of Ubuntu, FFmpeg and NGINX can publish to the chosen RTMPS endpoint just because each tool supports some form of streaming. The compatibility of the exact outbound route was not verified in this research; test it before scheduling a long run. If you insert NGINX, confirm whether it is receiving an incoming stream or publishing the relay, and which component is responsible for the secure outbound connection.
Keep the endpoint and key conceptually separate. The URL tells the encoder where to send the broadcast; the key identifies the stream. Never paste a real key into a public tutorial, issue report or command that will be shared. If you use a configuration file, protect it and avoid committing it to a repository. If a key may have been exposed, reset it in Live Control Room and update the publisher before going live again.
Once the encoder is sending, use Live Control Room’s preview and stream health information to check the incoming signal. YouTube’s encoder guidance says, “Make sure to test before you start your live stream.” For streams under 12 hours, YouTube says they are automatically archived; that does not remove the need to plan what happens after a long broadcast or to check the current platform guidance for your intended schedule.
For a broader view of a prerecorded broadcast path, our guide to streaming an online radio station to YouTube from Linux is relevant when your source is audio-led rather than a single video file. The same distinction applies: source playback, encoding and the destination’s ingest details are separate jobs.
Test the loop and diagnose failures
Test in stages so that a black preview does not leave you guessing which part failed. First verify that the selected NGINX binary starts and accepts its configuration. Then, if NGINX is part of the route, test that FFmpeg can publish to the intended local application. Finally test the outbound connection to YouTube and inspect the preview in Live Control Room. Keep a note of which stage works; that is more useful than changing several settings at once.
If NGINX fails to start, check the error log, configuration path and binary you are invoking. A common source-build complication is editing a configuration file belonging to one installation while running another binary. If the module directive or RTMP block is rejected, confirm whether the module was built into that binary or is meant to be loaded dynamically, and verify that the NGINX/module combination matches the build you made.
If FFmpeg cannot publish to NGINX, compare the URL it uses with the configured application and stream name, then check that the process is connecting to the correct host and port. If FFmpeg reports that it cannot open the media, inspect the path and file permissions. If it connects but the picture or sound is wrong, inspect the selected tracks and output profile, then compare the result with YouTube’s encoder recommendations.
If YouTube shows no incoming stream, check the URL and key in Live Control Room, the outbound network path and whether your selected RTMP or RTMPS route is supported by the actual tools in use. Do not expose the key while collecting logs. If YouTube reports unstable stream health, compare your chosen resolution and bitrate with the source and sustained upload capacity; reduce the output target if the connection cannot maintain it, then test again.
Finally, test the part most tutorials leave implicit: what happens at the end of the file and after an interruption. Watch beyond a loop boundary, check both audio and video, and simulate a controlled encoder stop or network interruption in a non-critical test. Decide who or what will notice a stopped process and how you will verify the stream has returned. These are validation tasks for your own implementation, not behaviour established by the build instructions. If you want to remove the burden of leaving your computer on and handling a dropped broadcast, StreamNeo turns an uploaded video into a YouTube live stream that runs with your computer switched off and is monitored and restarted if it drops.
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 installing NGINX RTMP make a video loop by itself?
No. The module gives NGINX RTMP server and relay functions; FFmpeg reads and publishes the media. You need to configure and test the playback and repeat behaviour in your own FFmpeg workflow.
Is there a verified Ubuntu 22.04 command here for looping indefinitely?
No. The upstream module documents FFmpeg integration, but the research for this guide did not verify a current, indefinitely looping command for Ubuntu 22.04. Test your chosen FFmpeg version, file, timestamp behaviour and recovery process before relying on it.
Can I use the NGINX Plus RTMP package on open-source NGINX?
The cited dynamic-module instructions describe NGINX Plus, not the open-source Ubuntu package path. Check the product and version documentation for the NGINX installation you actually use, and do not assume the package or module is interchangeable.
Where do I find the YouTube server URL and key?
Find them in YouTube Live Control Room’s encoder settings for the stream. Treat the key like a password, keep it out of public logs and screenshots, and reset it if it may have been exposed.