YouTube’s encoder guidance is the right starting point for an NGINX RTMP relay: use RTMPS when supported, constant bitrate (CBR), and a keyframe every two seconds, without exceeding four seconds. Choose the video bitrate for the codec, resolution and frame rate you are sending, then check that your upload connection can sustain it.
Those are output settings for the encoder, not magic NGINX directives. NGINX’s RTMP module handles the relay; its configuration and installation depend on the NGINX edition, build and module version. Test with representative audio and motion before launch, and monitor YouTube’s stream health while the channel runs. No single configuration guarantees uninterrupted 24/7 operation.
Start with YouTube’s supported output
Think of the path as two separate jobs. The encoder produces the audio and video stream, with a codec, resolution, frame rate, bitrate and keyframe cadence. NGINX receives and forwards that stream. Unless you have deliberately configured a transcoding workflow elsewhere, the relay does not turn an unsuitable encoder output into a suitable one.
YouTube’s current encoder guidance lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS ingest. That does not mean every encoder, NGINX module build or relay arrangement can produce or pass every codec. Check what your sending encoder actually emits and what the destination accepts before settling on a format. YouTube’s live encoder settings and bitrate guidance is the primary reference to check again when preparing a channel.
For a straightforward starting point, use a codec supported by your encoder and YouTube, select a resolution and frame rate appropriate to the material, set CBR, use a two-second keyframe interval, and choose the matching bitrate guidance. If you are relaying a pre-recorded devotional playlist, for example, there may be little benefit in sending a higher frame rate than the source contains. A study stream with a mostly still background has different picture demands from fast-moving footage, but both still need a stable, compatible output.
The relevant setting is the one in the program that originates the stream. If OBS, FFmpeg or another encoder sends video to NGINX, set the codec and keyframes there. If NGINX is only relaying the incoming feed to YouTube, changing an NGINX relay directive will not alter those encoder choices. For a separate workflow that sends a live source from a phone, the discussion of using a YouTube stream key for a continuous lofi radio broadcast can help clarify where the key and sending application fit.
Prefer RTMPS for the YouTube leg
YouTube recommends RTMPS, its secure extension to RTMP, for sending a live stream. Use it for the upstream connection to YouTube when your encoder or relay supports it. The point is the transport between the sending system and YouTube, not a change to the video codec or quality settings.
A relay setup may have two connections: an encoder sends to NGINX, and NGINX sends onward to YouTube. Decide the protocol for each leg based on what the receiving and sending ends support. Do not assume that using RTMPS on the NGINX-to-YouTube leg also secures an earlier encoder-to-NGINX connection; configure and assess the legs separately. Likewise, do not assume that a setting labelled “secure” changes the destination or stream key. Confirm the target YouTube ingest endpoint and key in the live control room.
RTMP can remain relevant where a device or local workflow only supports it. The practical choice is to use RTMPS on the YouTube leg when available, while avoiding an untested protocol change immediately before a long scheduled broadcast. Make a test stream, verify that YouTube receives it, and check the health status before replacing a known working configuration.
Set CBR and keyframes at the encoder
YouTube’s encoder guidance calls for constant bitrate and recommends a keyframe every two seconds, with the interval not exceeding four seconds. Apply both at the source encoder. A relay that forwards packets cannot reliably repair a variable-bitrate source or change its keyframe spacing simply because NGINX has been configured.
CBR aims to keep the encoded bitrate steady rather than allowing large swings as picture complexity changes. This is useful for ingest consistency, but it does not mean every moment has identical visual quality: the encoder still has to fit changing scenes into its configured rate. A quiet temple image, a scrolling news ticker and a moving dance performance place different demands on the encoder, even when the target bitrate is fixed.
The keyframe interval is the spacing between full reference frames. Two seconds is the practical target from YouTube’s guidance; longer intervals can make recovery and seeking less convenient, and the recommendation is not to exceed four seconds. Check the encoder’s actual setting, especially when it asks for frames rather than seconds. At 30 frames per second, a two-second interval corresponds to 60 frames; at a different frame rate, the frame count must change to preserve the same time interval.
Do not confuse this with NGINX RTMP settings such as chunk size. They concern relay or module behaviour, not the cadence of keyframes produced by the video encoder. Before launch, inspect the source encoder’s output or its logs rather than assuming a configuration label has taken effect. If you use a playlist workflow, make sure transitions and files do not cause the encoder to restart with different output parameters unexpectedly.
Choose bitrate for picture and connection
Bitrate depends on the incoming codec, resolution and frame rate. YouTube’s published H.264 recommendations illustrate why there is no universally correct target:
| H.264 output | YouTube recommended bitrate | YouTube minimum |
|---|---|---|
| 720p at 30 fps | 8 Mbps | 3 Mbps |
| 720p at 60 fps | 8 Mbps | 3 Mbps |
| 1080p at 30 fps | 14 Mbps | 5 Mbps |
| 1080p at 60 fps | 17 Mbps | 6 Mbps |
These figures are YouTube’s encoder recommendations, not guarantees of picture quality or a rule for other codecs. Match the row to the exact H.264 output you intend to send. If your resolution, frame rate or codec differs, consult YouTube’s current table rather than interpolating casually. The YouTube Live bitrate calculator by resolution and frame rate is also relevant when you are comparing output choices.
A published minimum is not a sensible target to use blindly for a channel that must run through a variable connection. YouTube advises testing upload bitrate and choosing a quality level that gives a reliable stream on the available connection. The upload capacity needs headroom for ordinary variation and other traffic; a speed test taken once does not establish that the connection will stay clear overnight. If your connection cannot sustain the selected output, reduce the resolution, frame rate or bitrate and retest rather than hoping the relay will absorb the shortfall.
For instance, if a H.264 source is 1080p30, 14 Mbps is YouTube’s recommended video bitrate and 5 Mbps its listed minimum. Those are figures for that row only. A connection that struggles to maintain the recommended rate may be better served by a lower output choice that the line can sustain consistently. Conversely, sending a low-motion 720p channel at a higher resolution setting does not automatically improve its source material and consumes more upload capacity.
Account for audio and protocol overhead when thinking about the total connection demand; the video bitrate is not the only traffic. YouTube lists AAC or MP3 audio, with AAC required for RTMP/RTMPS 5.1 surround. For stereo it lists 44.1 kHz and 128 kbps, while its 5.1 guidance lists 48 kHz and 384 kbps. If your channel is ordinary stereo music or speech, confirm the audio output is sensible and stable rather than selecting surround settings without a reason.
Separate module settings from encoder output
“NGINX RTMP settings” can mean two different things: NGINX’s ability to load an RTMP module, and directives within that module that govern how it receives or forwards streams. Neither category is a replacement for YouTube’s encoder requirements. Before copying a configuration from a forum or another server, identify your NGINX edition, operating system, package source and module version.
The NGINX Plus RTMP guide describes installing its compatible nginx-plus-module-rtmp package, loading ngx_rtmp_module.so in the main context, checking the configuration with nginx -t and reloading NGINX. Those package steps are specific to the documented NGINX Plus context; they are not universal instructions for every Open Source installation. NGINX’s Open Source installation guide explains that third-party modules may be built statically or dynamically, subject to the build and platform. Read the NGINX RTMP module guide for the edition and installation path you actually use.
A configuration directive accepted by one module build may be absent or behave differently in another. Use documentation for the exact module version, and validate changes before reload. A sensible change sequence is to save the current working configuration, make one small edit, run the configuration test, then reload and verify both the local relay and YouTube ingest. If the test fails, do not reload into an unknown state.
Some RTMP module configurations include HLS output directives for fragment length, playlist length, playlist type or storage path. These settings matter if the local NGINX instance also packages a stream as HLS for another consumer. They are not prerequisites just because the destination is YouTube Live. The commonly cited RTMP directives reference is community-maintained, so confirm each directive against your installed module version instead of treating it as a universal NGINX manual.
Avoid adding generic “retry” or chunk-size tweaks on the theory that they cure all drops. A relay directive may affect a specific module behaviour, but it cannot repair a failing internet connection, an exhausted source machine or a stream key mismatch. If the job is simply to keep a recorded playlist live, compare the operational implications with how to run a continuous YouTube playlist overnight before adding infrastructure you do not need.
Test representative audio and movement
A still test card is not enough if the real channel contains music, speech, moving visuals or scene changes. YouTube advises testing before starting, with audio and movement similar to the intended stream. Use a private or unlisted test workflow where appropriate, and watch the incoming preview and stream health while the encoder and relay run together.
Test the things that can fail differently at night than in a short setup check: a file boundary, a playlist transition, a long audio passage, a scene with more movement, and the actual selected resolution and frame rate. Listen for clipping, silence, channel imbalance or a loop that restarts incorrectly. Watch for frozen frames, dropped ingest, unexpected resolution changes, or encoder warnings. If your video is mostly devotional artwork with a song track, include an actual representative song and its transition, not only a silent image.
A useful preflight record includes the encoder profile, codec, resolution, frame rate, bitrate, keyframe interval, audio format, protocol on each connection, and the exact NGINX module build. Record whether the local relay accepted the source and whether YouTube reported a healthy incoming stream. That gives you something concrete to compare if a later change causes trouble.
Do not test by changing several variables at once. If the picture stutters, first establish whether the source encoder reports dropped frames, whether the source-to-relay connection is stable, or whether the relay-to-YouTube leg is the issue. Change one relevant setting, repeat the same test material, and record the result. That is slower than copying a random configuration, but it narrows the cause rather than obscuring it.
For a one-file channel that needs to continue while your personal computer is switched off, StreamNeo removes the specific burden of keeping a local encoder and relay machine running; it does not remove the need to check your YouTube channel and content requirements.
Monitor the stream after launch
A successful test tells you that the tested configuration worked at that time. It does not establish that a 24/7 channel will never drop. During operation, monitor YouTube’s stream health and review messages it displays about the incoming feed. YouTube’s encoder guidance recommends monitoring stream health during an event; for an always-on channel, make that a recurring operational check rather than something you only do at launch.
Check the source, relay and destination as separate points. Is the encoder still producing output? Is NGINX still receiving and forwarding it? Does YouTube show the stream as healthy and live? A viewer-facing outage can arise at any of those boundaries, and the remedy depends on which one failed. Keep access to the sending machine, service logs or relevant application status, and YouTube Live Control Room so you are not diagnosing from a viewer report alone.
For unattended use, decide who will notice a problem and what they can do about it. If the source application stops, someone may need to restart it; if the connection drops, an automatic retry may depend on the particular encoder or module. Do not assume a particular retry directive or supervisor exists merely because a sample configuration includes it. Check the documentation for the software and version you actually run, then test a controlled failure before depending on recovery behaviour.
Keep a change log for updates to NGINX, the RTMP module, encoder software, operating system and stream profile. A change that seems unrelated can alter module compatibility or output behaviour. Update one component at a time where practical, validate the configuration, then observe a representative test. If a continuous channel unexpectedly goes offline, the overnight outage troubleshooting guide offers a useful way to separate recurring source, relay and platform symptoms.
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
What keyframe interval does YouTube recommend?
YouTube recommends a keyframe every two seconds and says not to exceed four seconds. Set the interval in the encoder producing the stream, and convert seconds to frames using the actual frame rate if the encoder asks for a frame count.
What bitrate should I use for a 24/7 YouTube stream?
Use the YouTube recommendation matching your codec, resolution and frame rate, then test against the upload connection available to the sender. The H.264 figures in this article do not apply universally to other codecs or output formats, and a stable lower setting may suit a constrained connection better than a rate it cannot sustain.
Does NGINX need the RTMP module installed?
Yes, if you intend to use NGINX itself to receive or relay RTMP, it needs a compatible RTMP module in that NGINX build. Installation differs between NGINX Plus and Open Source, and a configuration copied from another edition or module version may not load.
Do NGINX settings guarantee that a 24/7 stream stays online?
No. NGINX settings can configure a compatible relay, but continuity also depends on the source encoder, network, module and YouTube ingest. Test representative material, monitor stream health, and make a recovery plan for the components you operate.