For YouTube Live with FFmpeg and NVENC, start with RTMPS, H.264, CBR and a keyframe every two seconds. Match the bitrate to YouTube’s recommendation for your chosen resolution and frame rate, then test whether your GPU and upload connection can sustain it.
Those settings are a starting point, not a promise of picture quality or real-time encoding. A small devotional loop and a fast-moving local news feed place different demands on the encoder, so test with the content you intend to broadcast and watch YouTube’s stream health before relying on it overnight.
Choose an ingest format and bitrate
For a broadly compatible SDR setup, use H.264 video and choose the bitrate listed by YouTube for the resolution and frame rate you plan to send. YouTube’s live encoder settings and bitrate recommendations include H.264, HEVC and AV1 as supported codecs, with a maximum frame rate of 60 fps. That does not mean each combination will work with every GPU or FFmpeg build; check your actual encoder and ingest path before settling on a codec.
Here are YouTube’s current displayed H.264 recommendations, accessed 3 October 2026. YouTube’s page did not expose a publication year in the retrieved material, so these should be treated as its current displayed guidance rather than figures assigned an invented date.
| Ingest resolution and frame rate | H.264 recommended bitrate |
|---|---|
| 2160p60 | 50 Mbps |
| 2160p30 | 42 Mbps |
| 1440p60 | 34 Mbps |
| 1440p30 | 21 Mbps |
| 1080p60 | 17 Mbps |
| 1080p30 | 14 Mbps |
| 720p60 | 8 Mbps |
| 720p30 | 8 Mbps |
| 480p30 | 4 Mbps |
| 360p30 | 4 Mbps |
For the common question, “What bitrate should I use for 1080p60?”, YouTube’s H.264 table says 17 Mbps. That is an ingest recommendation, not a guarantee that a stream at that bitrate will look clean or that your GPU can encode it in real time. A steady upload connection, suitable source material and successful end-to-end testing still matter.
Resolution and frame rate are choices with costs. More pixels can preserve detail in a busy scene, while a higher frame rate can make quick movement look smoother. Both can increase the encoding workload and the amount of data you send. If your source is a static bhajan visual with a slowly moving background, 1080p30 may be a more practical starting point than 1080p60; for sports or a rapidly changing news ticker, test the motion before deciding.
Use the recommendation for the resolution and frame rate actually sent to YouTube, not just the dimensions of your source file. If you scale a 4K recording to 1080p30 for ingest, choose the 1080p30 recommendation. For channel planning beyond encoder options, the guide to building a 24/7 Marathi music channel covers the programming side separately.
Set RTMPS and stream credentials
RTMPS is the encrypted transport option to prefer where available. YouTube’s live streaming setup guidance explains the setup flow and the stream key used by an encoder. In FFmpeg, the ingest address and key are part of the output destination, not a video encoding parameter.
Keep the stream key private. Treat it as a password: do not paste it into a public script, screenshot, support forum, or shared document. If other people need to operate the channel, use an access method you control and rotate the key if it may have been exposed. Check the live control room for the current server URL and key rather than relying on an old saved value.
A simplified destination often resembles rtmps://.../app/STREAM_KEY, but use the exact URL supplied for your stream and avoid publishing a real key in an example. In an FFmpeg command, options that apply to the input belong before the input declaration; output codec and rate-control options belong after it and before the destination. Misplacing an option can cause it to be ignored or applied to the wrong side of the pipeline.
RTMPS protects the transport in transit, but it does not make your source content private or decide who can view the YouTube broadcast. Set the stream’s visibility and audience settings in YouTube Studio, and confirm the channel’s live streaming access in advance. A valid key can still fail if the channel is not ready to go live or the selected ingest endpoint is wrong.
Configure H.264 NVENC
The h264_nvenc encoder uses NVIDIA’s hardware encoder rather than the software H.264 encoder. You need an NVIDIA GPU that supports the features you want and an FFmpeg build that exposes NVENC. Neither a generic “NVENC supported” label nor an example copied from another machine establishes that your particular GPU, driver and FFmpeg combination accepts every option.
Start by checking the local build’s encoder and option listings, for example with ffmpeg -encoders and the help output for h264_nvenc. Confirm that the encoder appears and that the option names and values you intend to use are accepted. FFmpeg’s NVENC H.264 option definitions can help explain available controls, but the moving source reflects a particular version and does not prove identical behaviour in every installed build.
A useful conceptual output fragment is:
-c:v h264_nvenc -preset p4 -tune ll -rc cbr \
-b:v <YouTube-recommended-bitrate> -maxrate <matching-bitrate> \
-bufsize <chosen-VBV-buffer> -g <twice-the-fps> -bf 2
This is a settings fragment, not a tested full command. Replace placeholders with values for your output and check the syntax supported by your build. The input source, scaling, frame-rate conversion, pixel format, audio mapping and destination all need deliberate choices too. A complete command copied without adapting those parts can produce the wrong output even if the encoder fragment looks plausible.
For SDR, YouTube’s advanced recommendations include square pixels, progressive scan, two B-frames, one reference frame, CABAC, Rec. 709 and 8-bit SDR. Make sure the source and filters produce a consistent format instead of assuming that an encoder option can repair a mismatched source. YouTube also lists AAC or MP3 audio; for stereo it recommends 44.1 kHz and 128 Kbps. These are platform recommendations to verify against the current official page, not guarantees of audio quality.
Use CBR and two-second keyframes
YouTube recommends constant bitrate (CBR) and a keyframe interval of two seconds, with four seconds as the maximum. In FFmpeg, -rc cbr selects constant rate control for NVENC in builds that support that value. Set the target bitrate and maximum rate consistently for a CBR starting point, and choose a buffer size appropriate to the build and workflow rather than treating an unexplained value as universal.
The GOP length, set with -g, is expressed in frames. For a two-second interval, use twice the output frame rate: at 30 fps that means 60 frames, while at 60 fps it means 120. If your command changes the frame rate, calculate from the output rate, not the input file’s original rate. Check actual keyframe behaviour in a test; the number in the command is not by itself proof that the encoder is emitting the cadence you intended.
NVIDIA’s FFmpeg with NVIDIA GPU Hardware Acceleration guide describes CBR with a one-second VBV buffer as its guidance for predictable bandwidth and performance in real-time game and studio broadcasting. That is NVIDIA’s scenario-specific advice. YouTube specifies CBR but does not require NVIDIA’s one-second buffer, so do not conflate the two recommendations. Buffer size affects rate-control behaviour and should be tested with your encoder build and stream.
CBR does not mean every frame carries identical visual detail. Complex movement can demand more bits to retain the same appearance, while static frames can be easier to encode. If your picture degrades during a fast pan or animated background, first check whether the source, bitrate, frame rate and GPU workload are appropriate together. Do not increase bitrate blindly: your uplink and the platform’s selected ingest format still impose limits.
Select a sustainable preset and tuning combination
NVENC presets balance encoding speed and compression quality. NVIDIA documents that the available choices and their trade-offs depend on the encoder and software context. A preset that gives one GPU adequate headroom may cause another setup to miss real time, especially when capture, scaling, compositing or other GPU work competes for resources.
Presets such as p4 or p5 can be sensible candidates to test, not universal best settings. Likewise, -tune ll is a low-latency starting point where the installed build supports it; check the accepted tuning values and what they do in that build. Do not copy a post-production example wholesale into a live command. A file-encoding command may use lookahead, buffering, GOP behaviour or rate control that does not fit a live ingest workflow.
A useful selection process is to begin with a conservative, supported configuration and observe it under the actual workload. If GPU utilisation is high or frames are missed, lower encoder complexity or reduce the output workload before assuming that a higher bitrate will help. If the encoder has ample headroom but motion looks soft, compare an adjacent preset and the bitrate YouTube recommends for that format. Change one relevant variable at a time so you can tell what changed the result.
The video equipment selection guide is useful if you are deciding whether to upgrade, but first verify what your existing model can do. The needs of an always-on static music visual are not the same as a multi-source live production. If your content is a fixed video rather than a live camera mix and you do not want your computer running throughout the day, StreamNeo can remove the need to keep that local machine encoding and relaying the file continuously.
Test motion and audio before going live
Test the whole route before announcing a broadcast: source file or capture, filters, NVENC output, RTMPS connection, YouTube ingest and playback. YouTube explicitly advises testing before a live stream. Use a private or unlisted test where appropriate, and make sure you understand the channel’s current visibility and event settings before changing them.
Choose a sample that resembles the hardest part of the planned programme, not just a still title card. For a devotional channel, include the animated background, transitions and any scrolling lyrics. For local news, test a moving camera shot and ticker. For a study stream, include the scene changes and any clock or visualiser that will remain on screen. Watch the received stream rather than judging only the FFmpeg log or the local preview.
Listen to the complete audio path as well. Check that speech or music is audible, stereo routing is correct if used, levels do not clip, and sound stays in sync with the picture. A video can connect successfully while the audio stream is missing, muted or mapped from the wrong input. YouTube’s recommended stereo settings give you a baseline, but your source and channel mix determine what needs adjustment.
Keep the test running long enough to expose a recurring issue: an input that stalls, a GPU that becomes busy after another application opens, or a network path that drops packets under ordinary household or workplace use. Record the output resolution, frame rate, preset, tuning, bitrate and relevant FFmpeg messages. Change only one setting between test runs, and note whether the change improves the received stream without causing a different failure.
For a recorded-video channel, the free software guide for running recorded lessons 24/7 can help with the broader playback workflow. It does not replace testing your specific encoder, audio mapping and YouTube ingest configuration.
Monitor YouTube stream health
A successful connection is only the beginning. During the test and the actual event, watch YouTube Studio’s stream health indicators and review any messages it presents. YouTube’s live encoder guidance tells broadcasters to monitor stream health during the event. Treat warnings as useful evidence: confirm which input, encoding or network condition they describe before changing several settings at once.
Also watch the local FFmpeg process. Look for encoder errors, dropped or duplicated frames, output timestamps that stop advancing, and signs that the process is unable to keep up. A command can keep running while the output is stalled or the YouTube preview is unhealthy. Compare the local log with the YouTube status and what a viewer can actually play; each is a different point in the path.
When a stream buffers, separate the likely causes. A viewer-side playback issue is not necessarily an encoder failure. A network warning may point to inconsistent upload, while an encoding warning may call for a lower workload or a different preset. If you need to investigate delivery symptoms, the guide to fixing a YouTube Live stream that keeps buffering offers a separate troubleshooting path.
Lower latency is not automatically better for a channel that does not need live audience interaction. YouTube notes that lower latency can increase buffering risk. For a devotional loop or study ambience station, reliable playback may matter more than reducing the delay between your source and viewers. Choose latency behaviour for the programme, test it, and avoid treating a low-latency tune as a general quality setting.
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 are the best YouTube Live streaming settings for FFmpeg with NVENC?
There is no setting combination that is best for every GPU and source. A practical starting point is RTMPS, H.264 NVENC, CBR, a two-second keyframe interval and YouTube’s H.264 bitrate recommendation for your output resolution and frame rate. Test the full workflow with representative motion and audio, then adjust based on stream health and whether encoding remains real time.
What bitrate should I use for 1080p60?
YouTube’s current displayed H.264 recommendation for 1080p60 is 17 Mbps. Your upload connection must sustain the stream, and the figure does not guarantee a particular visual result or prove that your GPU can encode at that rate. Confirm both with an end-to-end test.
Does -preset p4 work on every NVIDIA GPU?
No. Preset availability and performance depend on the GPU generation, driver, FFmpeg build and the rest of the workload. Check the options exposed by your build and test the chosen preset with the stream you intend to run.
Should I use low-latency tuning for a 24/7 loop?
Only if it suits the workflow and the installed encoder supports the option. A loop without real-time interaction may not benefit from pursuing the lowest possible latency, and YouTube notes that lower latency can mean more buffering. Test playback and stream health before keeping a tuning choice.