For 4K/2160p at 60 fps using H.264, YouTube’s recommended live video bitrate is 50 Mbps; its listed minimum is 14 Mbps. A sensible starting configuration uses CBR, RTMPS where available, and a two-second keyframe interval, but you must test it with your source, network and encoder before relying on it.
The command below is an untested example built around those ingest targets, not a guarantee that a particular computer can encode 4K60 in real time. Replace the input and YouTube ingest details, confirm your video really is progressive 3840×2160 at 60 fps, and watch stream health during a representative private test.
YouTube’s 4K60 H.264 ingest targets
YouTube’s live encoder guidance distinguishes a minimum bitrate from its recommended bitrate. For H.264 at 4K/2160p60, the minimum listed is 14 Mbps and the recommended video rate is 50 Mbps. Treat 14 Mbps as a floor in YouTube’s guidance, not as a quality target: using the minimum does not make it equivalent to the recommended rate, and it does not establish that a particular source will look good at that rate.
| Choice or setting | YouTube guidance for 4K/2160p60 | How to use it |
|---|---|---|
| H.264 minimum video bitrate | 14 Mbps | A listed minimum, not the recommended quality target |
| H.264 recommended video bitrate | 50 Mbps | The baseline target used in the example command |
| AV1 or H.265 minimum video bitrate | 10 Mbps | Relevant only if you choose one of those ingest codecs instead |
| AV1 or H.265 recommended video bitrate | 35 Mbps | A platform target, not a direct quality comparison with H.264 |
The comparison is useful only if you are free to choose a different codec. This page is about libx264, so H.264 is fixed; the practical decision is whether your upload connection can sustain the target and whether your machine can encode the material in real time. The other codec figures are YouTube’s recommendations, not a claim that one codec will look better under every circumstance.
YouTube recommends constant bitrate for live encoding and a keyframe interval of two seconds, with no interval longer than four seconds. At 60 frames per second, two seconds is 120 frames. YouTube also recommends RTMPS when supported. Its guidance for 4K streams does not offer the low-latency option; 4K live streams are optimised for quality at normal latency. Check the current YouTube live encoder settings before an event, since the official page is the place to confirm current ingest requirements.
The resolution and frame rate in the command are not created merely by writing -r 60. The source should already supply progressive 3840×2160 at 60 fps. If it does not, you need to decide deliberately whether to scale or convert frame rate; those operations alter the output and can add workload. A 30 fps source repeated into a 60 fps output does not provide the motion detail of actual 60 fps footage.
What the example command does
This baseline reads a file at its normal playback speed, encodes video with FFmpeg’s libx264 wrapper, encodes stereo audio as AAC, then sends the result through the FLV muxer to an RTMPS destination. It follows YouTube’s H.264 live targets, but its encoding preset and buffer choice are starting values to evaluate, not settings certified for your hardware.
ffmpeg -re -i INPUT \
-c:v libx264 -preset veryfast -profile:v high -pix_fmt yuv420p \
-r 60 -g 120 -keyint_min 120 -sc_threshold 0 -bf 2 -refs 1 \
-b:v 50M -minrate 50M -maxrate 50M -bufsize 100M \
-color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv 'rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY'
The line breaks and backslashes are for a Unix-like shell. On a Windows command prompt, line continuation syntax differs; either put the command on one line or adapt it to the shell you are using. The command is intentionally explicit so you can see the choices to inspect. FFmpeg builds vary, and you should check the options available in your installed build rather than assume every packaged version behaves identically.
-re paces a file input in real time. It is appropriate when feeding a stored video to a live endpoint; it is not a generic requirement for capture devices. For live capture, omit -re and select the correct device input options for your operating system and hardware. The FFmpeg documentation describes the encoder wrapper and its controls; consult the documentation and local help for your build when adapting the command.
The output URL is a placeholder. Do not run it unchanged: the example has no real input file, ingest URL or stream key. The output format is flv, a normal muxing choice for RTMP-family live output. If you change the protocol or destination, confirm that the destination accepts the chosen container and codec combination.
Replace the input, ingest URL and stream key
Start by replacing INPUT with the path to the video you intend to broadcast, such as /home/channel/loop.mp4. Quote paths containing spaces. Confirm that FFmpeg can read the file and that its video stream has the dimensions, scan type and frame rate you expect. A file labelled “4K” may use a different frame rate, and a progressive source is important for this baseline.
Next, open YouTube Live Control Room and copy the ingest details shown for the event or stream. Replace YOUR_INGEST_URL and YOUR_STREAM_KEY with the values supplied there; the exact URL structure is account- and session-specific, so do not copy a sample URL from an unrelated tutorial. Keep the stream key private. Anyone who obtains it may be able to send a broadcast to the associated stream, so avoid pasting it into public posts, screenshots or shared command histories.
A shell command can remain in terminal history, which matters if several people use the same computer account. If that is a concern, use a workflow for secrets that fits your operating system and team practice, and make sure logs or scripts do not expose the key. After a test, rotate or replace a key if you believe it has been disclosed; follow YouTube’s current account controls rather than relying on a copied menu path.
The command assumes a file input. If your content is a recurring playlist, input handling and reconnection behaviour become part of the design, not just an encoder flag. The guide to making an FFmpeg playlist repeat forever on YouTube Live covers the loop side of that problem. If the goal is a church recording rather than a 4K technical demo, the advice on streaming recorded worship songs without using mobile data may help you think through where the video is played from.
Configure libx264, frame rate and keyframes
-c:v libx264 selects FFmpeg’s software H.264 encoder. The veryfast preset is included as a possible starting point because encoding 4K60 in real time is demanding; it is not a universal recommendation. A slower preset can use more processing time to improve compression efficiency, while a faster preset can reduce the encoding workload at a possible quality cost. Neither choice makes an encoder capable of a workload its CPU cannot sustain.
-profile:v high and -pix_fmt yuv420p set a common 8-bit SDR H.264 compatibility combination. YouTube’s advanced live guidance calls for 8-bit SDR and square pixels; Rec. 709 is its recommendation for SDR colour. The three -color_... bt709 options label the stream’s colour characteristics. Labels do not repair incorrectly graded or incorrectly tagged source material. If your footage is HDR or uses a different colour space, do not treat these SDR values as a conversion workflow; use a deliberate, verified transform.
-r 60 requests a 60 fps output. It does not prove the input contains 60 distinct frames per second. Check the source first, and avoid unnecessary frame-rate conversion. -g 120 sets a maximum GOP length of 120 frames, which corresponds to two seconds at 60 fps. -keyint_min 120 and -sc_threshold 0 are included to aim for regular two-second spacing rather than allowing scene-cut decisions to shift keyframes. Confirm the actual behaviour with your FFmpeg and x264 build.
The -bf 2 and -refs 1 values reflect YouTube’s advanced guidance for B-frames and reference frames. They are explicit choices, not a promise that all builds or playback paths will behave identically. FFmpeg passes settings through its libx264 wrapper, and the available controls can depend on the installed build. Use ffmpeg -h encoder=libx264 or the relevant local encoder help to inspect what your version exposes. The official FFmpeg reference includes examples of libx264 wrapper options such as keyframe controls.
Set CBR bitrate and buffer values
The command sets -b:v, -minrate and -maxrate to the same 50 Mbps target. Together these express the intended constant-bitrate mode: the encoder is being asked to maintain a fixed video rate rather than freely varying its target. FFmpeg’s -b values are expressed in bits per second, so 50M means 50 megabits per second in this context. This is not the same unit convention used by x264’s own bitrate parameter when passed directly as an x264 option; avoid mixing the two forms without checking the relevant documentation.
The 50 Mbps number applies to video. The example adds AAC audio at 128 kbps, stereo, 44.1 kHz. That audio configuration follows YouTube’s listed stereo guidance for RTMP/RTMPS. It is useful to distinguish the video target from total upload demand: the connection must carry the encoded video and audio as well as protocol overhead, and practical network variation can affect whether a target is sustainable.
-bufsize 100M is an implementation choice in this example, not a YouTube requirement and not a claim about the amount of upload capacity you need. Buffering influences rate-control behaviour and how variation is managed; changing it can affect latency and rate dynamics. Keep it visible as a value to evaluate rather than copying it as a platform-mandated number. YouTube’s live guide sets the bitrate and keyframe expectations, not this particular FFmpeg buffer setting.
Before choosing 50 Mbps, test the upload path from the location and connection you will use for the actual broadcast. A speed-test result is only a snapshot; congestion, Wi-Fi conditions, competing devices and an ISP’s upstream performance can differ during a long stream. If you cannot sustain the recommended video rate with reasonable headroom, consider a lower output resolution or a codec option accepted by your workflow rather than assuming the 14 Mbps H.264 minimum will produce the same result. Check YouTube’s current live bitrate table for the mode you actually select.
Do not use YouTube’s upload-file encoding figures as a substitute for live ingest targets. Upload encoding is a separate workflow and has separate guidance, including a different rate-control context. The recommended upload encoding settings are useful if you are preparing a file for upload, but they are not the basis for this live command.
Test the command and inspect stream health
Use a private or otherwise controlled test before scheduling an event or leaving a channel unattended. Test with the same machine, source, connection and output settings you expect to use. Include motion and audio similar to the real programme: a static title card can conceal a performance problem that becomes obvious during a moving worship recording, animated study loop or news clip.
During the test, watch FFmpeg’s progress output. Check whether frames are being encoded at the expected pace and whether the process reports dropped frames or errors. Compare the output stream’s actual dimensions and frame rate with the intended mode. A running process is not proof that viewers are receiving a stable, correctly formatted stream.
Also inspect stream health and warnings in YouTube Live Control Room. Confirm that the platform sees the expected video and audio, that the bitrate is near the intended target, and that no warning indicates a mismatch or unstable contribution. YouTube specifically recommends testing with representative audio and motion, checking upload capacity and monitoring stream health. A brief test can reveal setup errors, but it cannot establish how a network will behave over a full night.
If the machine falls behind, test a faster preset or reduce the output workload, then repeat the test. If it keeps pace comfortably, you can evaluate whether a slower preset is practical, but judge the result with actual content rather than a preset name. The 60fps stutter troubleshooting guide can help structure checks when a stream stutters despite a stable bitrate. For a channel expected to run continuously, the article on cloud playout for a video channel running 24/7 discusses the operational distinction between operating a local encoder and having playback continue without keeping your own computer on.
If you plan to leave a local machine running overnight, account for restarts, power and network interruptions, software updates and a way to see whether the process has stopped. FFmpeg by itself is an encoder and sender; a command line does not automatically create a complete monitoring and recovery plan. StreamNeo removes the need to keep your own computer encoding a pre-recorded video continuously: upload the file, supply the YouTube stream key, and the broadcast can keep running from the cloud with monitoring and automatic restart if it drops.
A 4K60 live channel is also not the right fit for every source. A 1080p source upscaled to 4K adds encoding and upload load without adding genuine source detail. If your programme is a simple loop, or viewers mostly watch on phones, test the resolution that serves the material and audience rather than selecting 4K merely because it is available. The best live configuration is the one that your source, encoder and connection can sustain while delivering a useful picture.
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 60fps YouTube Live with H.264?
YouTube lists 50 Mbps as the recommended H.264 video bitrate for 4K/2160p60 and 14 Mbps as the minimum. Use 50 Mbps as the starting target in this example, then test whether your network and encoder can sustain it. The minimum is not a substitute quality target.
How do I set a two-second keyframe interval at 60 fps?
Two seconds at 60 frames per second is 120 frames. In the example, -g 120 sets the GOP maximum, while -keyint_min 120 and -sc_threshold 0 aim for regular spacing; verify the behaviour with your installed build.
Is this command tested or guaranteed to work on my computer?
No. It is an untested example based on YouTube’s published ingest targets and FFmpeg/libx264 controls. Your input format, FFmpeg build, CPU capacity, shell, network and YouTube ingest details all matter, so run a representative test before going live.
Should I include -re when sending a live stream?
Use -re to pace a file input in real time, as shown. For a live capture input, omit it and configure the appropriate capture device options instead. A file workflow and a live camera workflow do not use identical input handling.