For YouTube Live at 4K and 30 fps, a practical H.264 starting point is 3840×2160 output at 30 fps, 42 Mbps video, a two-second keyframe interval, and stereo AAC audio. Use RTMPS where available, and treat these as ingest settings to test—not evidence that your encoder or connection can sustain 4K in real time.
YouTube lists lower recommended bitrates for AV1 and H.265 than for H.264, but the right choice depends on the encoders available in your FFmpeg build and what your machine can handle reliably. YouTube’s 4K stream is offered at normal latency; there is no low-latency improvement option for 4K.
Start with YouTube’s 4K30 bitrate guidance
YouTube’s live encoder settings distinguish between codec and resolution. For 2160p at 30 fps, the published H.264 figures are 42 Mbps recommended and 11 Mbps minimum. The listed recommendation for AV1 or H.265 is 30 Mbps, with 8 Mbps as the minimum. These are YouTube’s ingest recommendations, not a promise of image quality, playback resolution or a workable result on every computer and connection. See YouTube’s current encoder settings before a production stream, in case its guidance changes.
| 4K30 ingest codec | YouTube’s listed minimum | YouTube’s listed recommendation | Practical consideration |
|---|---|---|---|
| H.264 | 11 Mbps | 42 Mbps | A straightforward starting point when a suitable H.264 encoder is available. |
| H.265 | 8 Mbps | 30 Mbps | Confirm encoder availability, performance and ingest support in your setup. |
| AV1 | 8 Mbps | 30 Mbps | Confirm the installed encoder and actual real-time performance before choosing it. |
H.264 is a useful baseline for an FFmpeg example because it is widely supported, but “widely supported” does not mean every build includes the same encoders or options. AV1 or H.265 may reduce the bitrate target shown in YouTube’s table; they are not automatically the better operational choice if your computer cannot encode them smoothly or you cannot verify what reaches YouTube. Check the selected codec in YouTube Studio and use the matching bitrate guidance.
Do not confuse the minimum with a target that must be reached at all costs. A lower bitrate may be appropriate during testing if the connection or encoder is struggling, although a lower rate can affect picture detail, particularly in moving scenes. The useful choice is the highest configuration that remains stable under representative conditions, not the largest number you can enter in a command.
For a channel that mainly plays a prepared file, the content itself still matters to the encoder. A still devotional image with a slow visual loop places a different workload on an encoder than fast cuts, rain over moving water or detailed footage. YouTube recommends tests with audio and movement similar to the actual stream. If you are planning a long-running playlist as well as its ingest settings, the practical points in how many videos a 24/7 stream can use help keep the content plan separate from the encoding decision.
Build an FFmpeg output for 3840×2160 at 30 fps
The following is an implementation example derived from YouTube’s published guidance and FFmpeg options. It assumes a file input, an SDR source, stereo audio, an FFmpeg build with libx264, and sufficient encoding and upload capacity. It is not a tested preset. Replace INPUT with your source file and RTMPS_INGEST_URL_WITH_STREAM_KEY with the RTMPS address and key copied from YouTube Live Control Room. Do not publish the key or leave it exposed in a command history or log.
ffmpeg -re -i INPUT \\
-vf "scale=3840:2160:flags=lanczos,fps=30,format=yuv420p" \\
-c:v libx264 -preset veryfast -profile:v high \\
-b:v 42M -minrate 42M -maxrate 42M -bufsize 84M \\
-g 60 -keyint_min 60 -bf 2 -refs 1 -coder cabac \\
-color_primaries bt709 -color_trc bt709 -colorspace bt709 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv "RTMPS_INGEST_URL_WITH_STREAM_KEY"
The filter requests 3840×2160, 30 frames per second and 8-bit 4:2:0 pixel format. That does not make low-resolution material native 4K: scaling a smaller source enlarges it without adding captured detail. If your source is already at the intended size and frame rate, avoid unnecessary conversion where practical. If you need to preserve a source’s aspect ratio or avoid upscaling, adapt the filter rather than forcing every input into 3840×2160, which can stretch or crop content depending on how you handle it.
The -re option reads a file at its native rate, which can help pace file playback for a live output. Do not add it to an actual capture device or live input; FFmpeg warns that real-time throttling can cause packet loss in that situation. If the programme uses a loop, transitions or overlays rather than one file, test that complete processing path, not just a short command against an easy sample. For a related example of sending programme audio through FFmpeg, see streaming an internet radio station to YouTube with FFmpeg.
Set GOP and rate control deliberately
YouTube recommends CBR and a two-second keyframe interval, with a maximum interval of four seconds. At 30 fps, two seconds corresponds to 60 frames, which is why the example uses -g 60 and -keyint_min 60. FFmpeg’s -g sets the GOP size; confirm the behaviour for the chosen encoder because some options and their interpretation vary by encoder. YouTube’s live streaming guidance is the source for the interval recommendation; FFmpeg’s documentation describes codec options and rate-control parameters.
In the example, -b:v, -minrate and -maxrate are set to the same 42 Mbps value to express a CBR-style configuration. The -bufsize 84M value is an example rate-control buffer sized at two seconds of that rate. It is an encoder control, not additional traffic to add to your upload calculation. Different encoders may implement or expose constant-rate behaviour differently, so consult the selected encoder’s help and verify the output rather than assuming that these options have identical effects everywhere.
A fixed target can make the stream’s upload demand more predictable, but it does not eliminate short-term variation or make an inadequate connection sufficient. Nor does a two-second GOP guarantee that a stream connects or stays live. If the encoder misses frames, the connection drops packets, or YouTube reports an unstable stream, inspect the logs and stream health before changing several parameters at once. Change one relevant setting, repeat the same test, and note whether the result improves.
The example uses the veryfast x264 preset as a starting workload choice, not as a YouTube recommendation. A slower preset may use more processing time to encode, while a faster one may trade encoding efficiency for lower workload. Try slower encoding only if your actual system keeps pace at 4K without missed frames. If it cannot, use a faster preset or an available hardware encoder, then verify that it supports the rate control and keyframe behaviour you need. FFmpeg’s encoder documentation and local encoder help are more useful than guessing from the preset name.
Configure SDR colour and audio
For SDR, YouTube’s guidance is Rec. 709 and 8-bit. In the example, the colour options tag the output as Rec. 709, while yuv420p requests an 8-bit 4:2:0 format. These tags do not convert a source from another colour space into Rec. 709. Check what the source actually contains; if it is HDR or uses different colour primaries and transfer characteristics, apply an appropriate conversion rather than relabelling it as SDR.
The audio options request AAC stereo at 128 kbps and 44.1 kHz. YouTube lists AAC or MP3 for stereo and gives 128 kbps at 44.1 kHz as its stereo guidance. Check that the source audio is present, that the channel layout is what you expect, and that dialogue, music or ambience does not clip or disappear in the test. A command can encode a silent or incorrectly mapped track quite successfully, so listen to the actual output.
If your programme is genuinely 5.1, use the requirements for that layout rather than applying the stereo settings blindly. YouTube lists 384 kbps at 48 kHz for 5.1 and supports 5.1 over RTMP/RTMPS only with AAC. Most simple music, devotional and ambience channels can keep their workflow easier to diagnose by using stereo unless there is a clear reason to deliver surround sound.
Use RTMPS and check the ingest path
YouTube supports RTMP and RTMPS and recommends RTMPS. Use the secure ingest address shown in Live Control Room when it is available to your setup. YouTube’s stream setup instructions explain where to find the stream key and configure the live event. The RTMPS URL and key are credentials: keep them out of public scripts, screenshots, support posts and shared logs, and reset the key if it has been exposed.
The command writes an FLV container to the ingest endpoint. Confirm that your FFmpeg build can make the connection and that you copied the URL and key correctly. A successful local process start is not proof that YouTube is receiving a healthy 4K stream. Open the Live Control Room and check the incoming preview, resolution and stream health. If the connection does not establish, first check the endpoint, key, network access and FFmpeg error output; do not immediately assume that the bitrate is the cause.
Latency is a separate decision from picture resolution and encoder rate. YouTube says 4K is optimised for quality at normal latency and does not have its low-latency improvement option. If near-live viewer interaction is central to your format, plan around that limitation rather than expecting a setting in FFmpeg to enable a 4K low-latency mode. For a pre-recorded programme, a delay may be acceptable; for a call-in or live question session, decide whether the latency trade-off fits before building the show around it.
An always-on channel also needs a plan for gaps in the programme, not just ingest settings. If you use a holding card between clips, make sure it is part of the source or output path and test its audio behaviour. The guide to showing a branded holding screen between videos covers that content problem without changing the codec settings described here.
Test encoder and upload capacity
A 42 Mbps target tells you what YouTube recommends for H.264 ingest at 4K30; it does not tell you what your computer can encode or what your internet connection can continuously upload. Those are separate limits. Encoding capacity depends on the selected encoder, preset, source complexity and any filters. Upload capacity depends on the usable connection during the stream, including contention and variation over time. A speed-test result is a useful check, but it cannot by itself prove that a long broadcast will remain stable.
Allow headroom above the selected video rate because audio and protocol overhead also use the connection. YouTube’s practical guidance is to choose a quality that is reliable for the available connection; do not treat the listed video bitrate as the total upload requirement. If other devices share the connection, test while they are in their normal use rather than assuming the connection is idle for the event.
Run a private, unlisted or otherwise appropriate test before relying on the setup. Use the same source type, motion, audio, filters, encoder and network that the real stream will use. YouTube specifically recommends including movement and audio like the planned broadcast. A static test screen can hide problems that appear during fast motion or a busy section of the programme. Keep the test long enough to observe the actual stream health and encoder behaviour, and review logs for missed frames, disconnects or bitrate instability.
If the machine cannot maintain real-time encoding, reduce the processing load, try a faster preset or a suitable hardware encoder, and repeat the test. If upload is unstable, lower the target bitrate or resolution and check again; choosing a lower resolution may be more useful than repeatedly pushing a stream that drops. If the input is a file and there is no need to produce 4K from it, avoid upscaling purely to meet a label. The right result is the best stable output your particular source, machine and network can sustain.
For a channel intended to run while you are away, consider the operational burden as well as the FFmpeg command. A local computer needs to remain powered, connected and watched, and a dropped process needs attention. When that is the specific pain you need to remove, StreamNeo lets you upload a video and use your YouTube stream key to run the broadcast without leaving your own computer switched on; that does not remove the need to check your source, key, ingest settings and channel before starting.
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 bitrate should I use for 4K 30fps YouTube Live in FFmpeg?
For H.264, YouTube lists 42 Mbps as recommended and 11 Mbps as the minimum for 4K30. For AV1 or H.265, the listed recommendation is 30 Mbps and the minimum is 8 Mbps. Use the figures for the codec actually being sent, then test whether your encoder and upload can sustain it.
What keyframe interval should I set at 30 fps?
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. At 30 fps, a 60-frame GOP is two seconds, so -g 60 is a suitable starting point. Verify the selected encoder’s GOP behaviour rather than relying on an option name alone.
Can I use YouTube’s low-latency option for a 4K stream?
No. YouTube’s guidance says 4K is intended for normal latency and has no low-latency improvement option. Decide whether normal latency suits the programme before promising rapid viewer interaction.
Does this FFmpeg command guarantee a stable 4K broadcast?
No. It expresses a starting configuration based on YouTube’s published ingest settings, but it cannot establish your computer’s real-time encoding ability or your connection’s sustained upload capacity. Test the complete programme path with realistic motion and audio, check YouTube stream health, and reduce the workload, bitrate or resolution if the result is unstable.