There is no universal CPU or RAM minimum for sending one 1080p loop through NGINX RTMP to YouTube. The right host depends on whether it relays an already encoded stream, transcodes it, records it, or packages it for other delivery.
Start by defining those jobs, then match the output settings to the intended frame rate and test the complete path under sustained load. A 1080p label alone does not tell you how much work the machine must do.
Define the 1080p loop workload
A loop stream is a video source that continues to be sent to YouTube as a live broadcast. It might be a finished MP4 of devotional music, a local news bulletin loop, an ambience scene, or a sequence assembled from several clips. The file may be prepared before the stream starts, or a process may read and repeat it continuously. Those choices affect operations, but the decisive sizing question is what the NGINX host does with the encoded audio and video.
Write down the intended output before choosing a machine: resolution, frame rate, video codec, video bitrate, audio format, and whether the source already meets those requirements. “1080p” commonly means 1920 by 1080 pixels, but does not say whether the stream is 30 or 60 frames per second. That distinction matters both to YouTube’s recommended bitrate and to encoding load.
Separate four possible roles:
| Role | Main additional demand | Sizing question |
|---|---|---|
| Relay an encoded feed | Sustained network path and process supervision | Can the host forward this exact feed reliably? |
| Transcode with FFmpeg | CPU or supported hardware-encoding capacity | Can the chosen encoder produce the target in real time? |
| Record locally | Storage capacity and write activity | How long must recordings be retained, and at what format? |
| Package HLS or DASH | Processing, storage, and delivery for segments | Who receives those outputs, and how much traffic will they create? |
A single setup can combine these roles, so do not treat each row as an alternative if your design needs several. A relay that also records has a different storage profile from a relay that only forwards packets. A transcoder that publishes to YouTube and packages a separate viewer feed has additional outputs to test.
There is no source-backed, universal NGINX hardware minimum for one 1080p relay. The NGINX module documents capabilities, not a fixed CPU, memory, disk, or network-interface specification for every deployment. A small test workload on one distribution may not predict another combination of module build, encoder, source file, and network route.
If the source needs preparation, consider that work separately from the live path. You can use a known-good output profile and check the YouTube upload settings guide while preparing the file; upload settings and live ingest are related, but not identical. A live stream still needs the correct encoder output and an active ingest connection.
Distinguish relay from FFmpeg transcoding
In a relay design, a source sends an already encoded stream to NGINX, and NGINX forwards it to YouTube. The relay is not decoding and re-encoding each frame. That generally avoids an encoding workload on the relay machine, though it does not make the host irrelevant: it must keep the connection open, move the data over the intended route, and recover sensibly from failures.
The nginx-rtmp-module project documentation describes push and pull relay as well as FFmpeg-based transcoding examples. These are distinct operations. A push directive publishes a stream to a remote destination; FFmpeg can read a published stream, transform it, and publish a new output. Do not call a relay “transcoding” merely because the source passes through an NGINX process.
Transcoding is relevant when the source does not match the target or when you need to change resolution, frame rate, codec, bitrate, or keyframe cadence. FFmpeg then has to decode and encode video in real time. The cost varies with the input, output settings, codec, software or hardware encoder, preset, quality target, and concurrent outputs. A command that handles one low-complexity source may not handle a different feed or a more demanding output at the same rate.
That is why generic vCPU counts are a poor substitute for a benchmark. For a transcode, use the exact FFmpeg command and encoder you intend to deploy, with the actual source and output settings. Check whether the process can keep pace with the source over time, not just whether it starts successfully. Record CPU use, memory use, output continuity, and any dropped or late frames while the job runs.
| Design | What it changes | What to test |
|---|---|---|
| Relay-only | Forwards an existing encoded feed | Network stability, reconnect behaviour, CPU and memory under the real feed |
| FFmpeg transcode | Produces a newly encoded output | Sustained encode speed, output quality, CPU or encoder capacity, and concurrent jobs |
If you are unsure which design applies, inspect the stream that will be published to NGINX. If it already has the codec, resolution, frame rate, bitrate, and keyframe interval you intend to send to YouTube, relay may be sufficient. If not, decide whether to re-encode the file before the live session or transcode continuously. Pre-encoding can move work out of the live path, but only if the prepared file is suitable and the loop player can send it in the required form.
Account for recording and packaging
Recording changes the resource picture even when the stream is only being relayed. Each written copy consumes disk space, and retention determines how much space you need. Estimate it from the actual encoded output and the hours you intend to retain, then leave room for filesystem overhead and operational headroom. Do not assume that a relay’s low CPU use means a disk can be ignored.
A recording can be useful for recovery and review: if the source stops, you may have a copy of what was sent; if a stream health warning appears, you can inspect the output. But recording is not a replacement for monitoring the live ingest. Decide whether the saved copy should contain the encoded source or a transformed output, where it will be kept, and what happens when storage runs low. Test disk alerts and rotation rather than allowing a full volume to become a surprise failure mode.
HLS or DASH packaging is another separate role. It creates segmented outputs for playback paths beyond the YouTube ingest connection. The module supports packaging features, but that fact does not tell you how much storage or delivery capacity your particular audience requires. Segment retention, number of renditions, viewer count, and whether the same host also serves the files all affect the design. Size and measure those outputs as their own workload.
For a small creator who only wants YouTube to receive a loop, local recording and HLS/DASH may be unnecessary. Every added function makes testing and operations more involved. For a station that needs a local archive or a separate web player, the added role may be worth it, but it should be explicit in the host plan.
Keep the loop’s editorial and rights checks separate from server sizing. A technically stable relay cannot resolve a music rights issue or ensure that a broadcast is suitable for the channel. For recordings where audio continuity matters, this guide to keeping background music across a video loop covers a source-side concern that sits alongside, rather than inside, NGINX capacity planning.
Estimate network needs from frame rate and bitrate
The network requirement is about the encoded stream plus its audio, protocol overhead, other traffic, and enough margin for variation. YouTube’s current H.264 recommendations are 5 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps, as listed in its live encoder settings guidance. These figures describe recommended video bitrates for those resolution-and-frame-rate combinations; they are not CPU requirements or guaranteed bandwidth specifications for an NGINX host.
Audio adds to the transmitted rate. YouTube’s guidance lists 128 Kbps for stereo audio and 384 Kbps for 5.1 audio. Those audio rates do not replace the video rate, and the path also has protocol overhead and may carry unrelated traffic. Do not provision a route whose measured sustained upload merely equals the video figure and assume it will be adequate.
For example, a 1080p30 H.264 loop at YouTube’s recommended 5 Mbps video rate with stereo audio at 128 Kbps needs capacity above the combined encoded payload, with additional room for overhead and variation. A 1080p60 H.264 loop at the recommended 12 Mbps video rate calls for a more capable sustained upload path. In both cases, test the route from the actual host to the intended ingest, at the time and conditions in which you expect it to operate. A speed test from a different device or location is not a measurement of that complete path.
If the loop is already encoded, raising the server’s network capacity does not improve picture quality by itself. If you transcode, the output bitrate you configure determines the approximate stream traffic, while the encoder workload is a separate question. When several streams run at once, account for their combined outputs. Likewise, an HLS or DASH output served to viewers creates delivery traffic beyond the one YouTube push.
The practical margin is not a magic multiplier. Watch the host’s sustained upload, interface errors, drops, and stream health while the actual output is running. If the route is shared, identify competing jobs such as backups or file transfers. For a local machine, consider whether the connection, router, and power arrangements are suitable for continuous use; a capable processor cannot compensate for a route that repeatedly disappears.
Set CBR and keyframe interval appropriately
For YouTube ingest, configure the encoder to use constant bitrate (CBR) and a two-second keyframe interval. YouTube’s guidance says the keyframe frequency should be two seconds and not exceed four seconds. Apply that to the stream being delivered to YouTube, whether FFmpeg encodes it or another encoder prepares the source. A relay cannot correct settings that are already baked into an encoded feed.
A keyframe is a reference frame that helps a decoder begin or recover video. Regular keyframes make the stream more predictable for ingest and playback. If you transcode, verify the encoder’s keyframe setting in the actual command or profile; if you relay, inspect the source output rather than assuming the NGINX configuration changes its cadence.
Bitrate and frame rate should be considered together. For YouTube’s recommended H.264 settings, 1080p at 30 fps uses 5 Mbps video, while 1080p at 60 fps uses 12 Mbps video. These are not interchangeable presets: a 60 fps target carries more frames each second and has a different recommendation. If the source is 30 fps, sending it through a 60 fps transcode does not create new motion detail, but it can add encoding work and increase the recommended output rate.
Codec choice also changes the recommendation. YouTube lists different figures for H.264, H.265, and AV1, so do not take an H.264 rate and apply it without checking the chosen codec. The examples here focus on H.264 because it is a common encoder path; check the current official table for the actual combination you plan to send.
After setting the profile, verify what leaves the encoder. Confirm resolution, frame rate, codec, measured bitrate behaviour, audio format, and keyframe spacing. A configuration label in a graphical tool is not proof that the encoded feed has those properties. A short local capture or stream inspection can help confirm the output before it becomes a long-running broadcast.
Use YouTube’s ingest URL and stream key
Create or select the live event in YouTube Studio and use the ingest details shown for that event. The URL and stream key are the destination and credential for the encoder or relay. Treat the key as private: do not put it in a public configuration example, screenshot, support post, or repository. If it is exposed, replace it through the platform’s current controls.
YouTube recommends RTMPS, a secure form of RTMP. Its Live Streaming API documentation describes ingestion addresses and stream names or keys, including primary and backup ingest. Use the exact address and key supplied for your stream setup rather than copying an address from an old tutorial. YouTube may present different details depending on the event and workflow.
Check that the chosen NGINX distribution and RTMP module support the protocol path you intend to use. Stock NGINX does not automatically include every RTMP capability. The open-source module project describes a build route, while NGINX’s RTMP module documentation covers its own dynamic-module packaging instructions. Those package instructions do not automatically apply to every open-source distribution or operating system. Verify the module build, platform compatibility, and TLS/RTMPS support in your environment before configuring the live path.
Keep credentials out of the client-facing part of an article or public log. In your own setup, store the key where the relay process can read it without making it broadly visible to other users. Redact it from diagnostic output before sharing logs. These are operational precautions, not a promise that any particular configuration is secure or approved by YouTube.
Once configured, confirm that YouTube receives the stream and reports a healthy feed before relying on it. If the stream does not appear, check the destination URL, key, selected event, and outbound connection, then review encoder and host logs with secrets removed. This automatic restart guide addresses recovery behaviour; restarting helps only when the underlying source and route can reconnect correctly.
Test the actual host under sustained load
A useful test resembles the job you intend to run, not a synthetic estimate based only on a processor label. Use the actual loop file or live source, target codec and frame rate, output bitrate, destination, and NGINX module build. Include FFmpeg if it will transcode, and include recording or packaging if those functions will be enabled. Run any other simultaneous tasks that will share the host or network.
Observe CPU and memory use, sustained upload, dropped frames, disconnects, reconnect behaviour, disk writes, and storage growth. For a transcode, note whether FFmpeg maintains real-time output and whether the picture remains acceptable. For a relay, look for signs of network congestion or process instability rather than expecting the CPU to behave like an encoder. Compare the host’s measurements with YouTube’s stream health indicators, since local process health alone does not establish that the ingest is receiving a good feed.
Test recovery deliberately. Interrupt the source or connection in a controlled setting, then observe whether the process reconnects, whether the stream resumes, and what the viewer sees. Check how the system behaves after a process restart or host reboot. Do not infer reliable operation from a successful launch or a brief preview. YouTube advises testing before a stream and monitoring stream health; it does not specify a universal duration for a 24/7 soak test.
A modest self-hosted machine may suit someone who already has a reliable always-on system and can maintain its OS, module build, network, power, and recovery process. A hosted machine may suit someone who needs a separate always-on environment or a particular network route, but the provider’s advertised instance size alone does not demonstrate sustained performance for your workload. Select either on measured results and operational access, not a generic claim that a certain number of cores is always enough.
If managing a host, reconnect logic, and overnight checks is the part that repeatedly fails, StreamNeo removes that specific burden by taking an uploaded video and running it as a YouTube live stream while your own computer is off. It is YouTube-only, so it is not the right path if you need to operate an NGINX relay for other destinations or want to control the server configuration yourself.
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 much CPU and RAM does an NGINX RTMP server need for one 1080p stream?
There is no universal minimum supported by the reviewed documentation. A relay and a real-time FFmpeg transcode do different work, and recording or packaging adds further demands. Choose based on the exact workload and test it on the intended host.
Is NGINX RTMP enough to loop a video to YouTube?
NGINX RTMP can relay streams, but a loop source still has to be produced and published in a compatible form. If the file needs to be decoded, repeated, or re-encoded, you need an appropriate source/player or FFmpeg process in addition to the relay configuration. Test that complete chain rather than assuming the module itself loops any file.
What bitrate should I use for 1080p?
For YouTube’s recommended H.264 ingest settings, use 5 Mbps at 1080p30 or 12 Mbps at 1080p60, as listed in its current encoder guidance. State resolution, frame rate, and codec whenever you quote a rate, and account separately for audio and network headroom. Check YouTube’s current page before configuring a live stream.
Can I use the same setup for HLS or local recording?
Possibly, but those are additional roles, not automatic consequences of relaying to YouTube. HLS/DASH packaging creates outputs to store or deliver, while recording consumes disk over time. Test and size each requirement independently, including retention and viewer delivery if applicable.