For a file-based 4K60 YouTube Live stream on Ubuntu 24.04, use FFmpeg to send a real-time video feed to YouTube’s current RTMP or RTMPS ingest endpoint. First check that the source, chosen codec, FFmpeg build and upload connection can support the target; a command by itself cannot guarantee a successful broadcast.
YouTube recommends 50 Mbps for H.264 at 2160p and 60 fps, or 35 Mbps for H.265/HEVC or AV1. Its guidance also calls for constant bitrate (CBR) and a two-second keyframe interval. Treat these as ingest recommendations, not proof that your particular system can sustain 4K60 overnight.
Check YouTube’s 4K60 ingest requirements
The target format is 3840 × 2160 pixels at 60 frames per second. YouTube’s live encoder settings and bitrate guidance gives different bitrate recommendations by codec. At 2160p60, H.264 has a recommended ingest bitrate of 50 Mbps and a listed minimum of 14 Mbps. H.265/HEVC and AV1 each have a recommended rate of 35 Mbps and a listed minimum of 10 Mbps.
The minimum is not a sensible planning target for a channel that needs stable picture quality. It is a lower bound in YouTube’s published table; the recommended figure is the more appropriate starting point for configuring an encoder. Neither number guarantees smooth delivery. The encoder must produce the selected rate, and the connection needs enough dependable upstream capacity for the stream and normal network variation.
YouTube recommends CBR and a keyframe every two seconds, with no more than four seconds between keyframes. At 60 fps, two seconds corresponds to 120 frames. If you are using a variable frame rate source or a different frame rate, do not blindly use a 120-frame interval: frame count and elapsed time are related to the actual output frame rate.
For SDR, YouTube’s guidance specifies Rec. 709 and 8-bit video. For HDR, it specifies 10-bit and recommends H.265; AV1 is not supported for HDR in the cited guidance. Codec, pixel format, profile and colour characteristics need to agree with the source and selected encoder. A file with a 4K label is not necessarily a suitable 4K60 input.
YouTube lists RTMP and RTMPS for supported live ingest. Prefer RTMPS when the workflow and build support it, because the connection is encrypted in transit. Use the endpoint shown for your broadcast in Live Control Room rather than guessing a host or copying an old example. The FFmpeg protocol documentation describes RTMP and its RTMPS variant, but it does not verify that your YouTube event or local build is configured correctly.
Inspect the file and Ubuntu build
Before choosing whether to copy or re-encode, inspect the media. ffprobe is part of many FFmpeg installations and can report the video and audio streams. For a readable overview, try:
ffprobe -hide_banner input.mp4
Check the video codec, width and height, reported frame rate, pixel format and bitrate. Also note whether the file contains audio, what codec it uses, and whether it has multiple audio tracks. A 3840 × 2160 file at 30 fps does not become 60 fps simply because the output command asks for 60; frame-rate conversion may duplicate or otherwise generate frames, and it cannot create genuine motion detail absent from the source.
Check which FFmpeg you are running before relying on an encoder option:
ffmpeg -version
ffmpeg -encoders
The version and build configuration matter. The Ubuntu 24.04 FFmpeg manpage documents options and hardware acceleration paths such as VAAPI and QSV, but an option is useful only when the installed build, driver, device and selected decoder/encoder support it. Do not assume that an Ubuntu installation has a working NVIDIA, Intel or AMD encoding path, or that hardware encoding will sustain 4K60.
If your chosen software encoder is present, you can test it on a short local output before configuring YouTube. If you intend to use hardware encoding, verify the encoder’s availability and the relevant device access first, then make a local test. A failing hardware option is not fixed by adding more flags to the command; use an encoder the actual system supports or investigate its configuration.
Choose a codec and bitrate
The useful comparison is YouTube’s codec recommendation alongside compatibility and the capacity you can sustain. These published rates concern the video stream; audio is additional. The recommendations and minimums below are from YouTube’s current encoder guidance accessed in 2026, not measurements of your machine.
| Codec at 2160p60 | YouTube recommended video bitrate | Listed minimum | Practical consideration |
|---|---|---|---|
| H.264 | 50 Mbps | 14 Mbps | A straightforward starting path when the FFmpeg build and workflow support H.264 encoding. |
| H.265/HEVC | 35 Mbps | 10 Mbps | Lower recommended ingest rate than H.264; confirm encoder and ingest compatibility. YouTube recommends it for HDR. |
| AV1 | 35 Mbps | 10 Mbps | Lower recommended ingest rate than H.264; confirm encoder and ingest compatibility. YouTube guidance does not support AV1 for HDR. |
Choose based on a combination of source characteristics, encoder support, intended SDR or HDR format and reliable upstream capacity. A lower recommended bitrate does not automatically make a codec the right choice: encoding support may be absent, or the source may need a particular colour and bit-depth treatment. For many first tests, H.264 is the simplest example to follow, but only if your build has a suitable encoder and the connection can carry the recommended rate with headroom.
If your upload connection is marginal, do not solve that by treating the listed minimum as a promise of acceptable quality. Test the actual connection under realistic conditions, and consider a lower resolution or frame rate if the available sustained capacity is insufficient. Avoid running other uploads during the test where possible. The goal is stable ingest with representative content, not merely seeing an image appear once.
Decide between stream copy and re-encoding
If the input already has the desired resolution, frame rate, codec, pixel format, audio and keyframe cadence, stream copy may be appropriate. Copying avoids a fresh encode, so it reduces local processing work and preserves the encoded media. It also means FFmpeg does not correct an unsuitable input: a 30 fps file remains 30 fps, and its bitrate and keyframes are not made compliant by copying.
A copy-style command pattern may look like this, once you have substituted the actual endpoint and key safely:
ffmpeg -re -i input.mp4 \
-c copy \
-f flv 'rtmps://INGEST_HOST/live2/STREAM_KEY'
This is a pattern, not a universal working command. The endpoint path, codecs in the file, stream mapping, FFmpeg build and YouTube event settings all affect whether it works. If the source contains multiple audio or subtitle streams, you may need explicit mapping rather than copying every stream. Check the event’s incoming format and messages in Live Control Room before relying on it.
If the source needs conversion, use a supported encoder and choose output settings intentionally. Re-encoding consumes CPU or hardware encoding capacity, and a local encode that cannot keep up with real time will cause trouble at ingest. Inspect the file first, test a representative section and confirm the output settings rather than assuming that scaling and frame-rate flags guarantee the desired result.
Build an illustrative H.264 command
The following example shows a common file-to-RTMPS pattern for an H.264 output. It is illustrative, not a tested end-to-end command for every Ubuntu installation or source file:
ffmpeg -re -i input.mp4 \\
-vf 'scale=3840:2160,fps=60' \\
-c:v libx264 -pix_fmt yuv420p \\
-b:v 50M -maxrate 50M -bufsize 100M \\
-g 120 -keyint_min 120 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://INGEST_HOST/live2/STREAM_KEY'
Here, -re reads the file at its native playback rate rather than feeding it as fast as the disk can supply data. FFmpeg documents this real-time input pattern for files and FLV output to an RTMP server. The -f flv output format is used for the RTMP-family workflow; RTMPS is the encrypted protocol variant. The video bitrate settings are shaped around YouTube’s 50 Mbps H.264 recommendation. The 100 Mbps buffer is an illustrative encoder setting, not a YouTube requirement.
The filter scales to 3840 × 2160 and requests 60 fps. That can upscale a smaller image and can duplicate frames from a lower-frame-rate source; neither operation restores missing detail or motion. If the input already meets the target, avoid unnecessary filtering unless conversion is required. The pixel format, audio settings, scaling behaviour and stream mapping should be adjusted for the actual source and the current YouTube guidance.
At 60 output frames per second, -g 120 sets a 120-frame GOP, corresponding to two seconds. -keyint_min 120 and -sc_threshold 0 help hold a regular interval with this encoder configuration. These options are encoder-specific; confirm how your selected encoder interprets them. A setting that works with libx264 should not be assumed to work unchanged with a hardware encoder.
For HEVC or AV1, substitute a compatible encoder and use the corresponding YouTube recommendation as a starting point. Do not simply replace libx264 with an encoder name found in an online example. Check ffmpeg -encoders, the installed build documentation and the encoder’s own options. The codec, profile, pixel format, HDR or SDR signalling, rate control and keyframe configuration need to agree. If you cannot verify the chosen path, begin with a short test using a supported configuration rather than launching a long broadcast.
Retrieve the current ingest URL and key
Open YouTube Live Control Room for the event you intend to use. Retrieve the ingest URL and stream key from the current stream setup there, and use those values in place of INGEST_HOST and STREAM_KEY. The placeholder in the examples is deliberately not a real key or usable endpoint. Do not infer your URL from an example or reuse a value without checking that it belongs to the event and configuration you plan to run.
The stream key functions as a credential: anyone who obtains it may be able to send a feed to your channel’s live ingest. Do not paste it into a public forum, include it in a screenshot, commit it to a repository or put it in a shared script. Avoid posting terminal output containing the full command. If you believe the key has been exposed, manage or reset it through YouTube’s current Live Control Room controls, then update your local configuration.
RTMPS is preferable when available in the YouTube workflow and supported by your build. It protects the stream transport, but it does not make a key safe if you publish that key yourself or leave it exposed in a shared environment. The key remains sensitive even in a command that uses an encrypted endpoint.
Protect the key and test stream health
A literal key in a shell command can be saved in shell history, process listings or diagnostic logs, depending on how you run the command and the system configuration. For a one-off test, take care not to share the terminal, its history or captured logs. For a repeatable workflow, keep credentials in a file with restricted access or another appropriate secret-handling method, and avoid writing the resolved command to logs. A private script is still a file that needs sensible permissions and careful backups.
Test before starting a public or scheduled broadcast. YouTube explicitly advises testing, including audio and movement similar to the intended stream, then monitoring stream health and reviewing messages during the event. A static image with silence is a poor test for a devotional loop with continuous audio or a news loop with rapid scene changes. Use a short representative segment and confirm the incoming resolution, frame rate, codec and audio in Live Control Room.
Watch both the encoder and YouTube’s ingest status. FFmpeg output can reveal an encoder that is falling behind or a connection error; YouTube’s stream health messages can reveal ingest problems. A green-looking preview at the start is not evidence that the same system can run through the night. Check that the upload connection stays adequate while other normal household or business traffic is present, and monitor again after launch.
If the stream health check remains stuck or does not show the expected format, work through the event status and connection before repeatedly restarting. This guide to a YouTube stream health check stuck on checking covers practical troubleshooting. If the issue appears only after a long run, compare logs and the point where output stopped with this guide to a 24/7 stream that stops.
A prepared file is not a promise of uninterrupted operation. If you need an always-on channel, consider whether keeping a computer encoding and connected all day is the right operational choice. This comparison of OBS and FFmpeg for a pre-recorded 24/7 stream explains the difference between local encoding approaches. For a workflow where switching off your own computer would remove a source of interruptions, StreamNeo can take an uploaded video and keep the YouTube broadcast running without that computer left on.
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
Can FFmpeg turn any video into a genuine 4K60 stream?
No. It can scale and change the output frame rate, but upscaling does not create source detail and converting a lower frame rate may duplicate frames. Inspect the source and test the result before deciding that it is suitable for a 4K60 broadcast.
Is 50 Mbps enough for H.264 4K60?
It is YouTube’s recommended video ingest bitrate for H.264 at 2160p60, not a guarantee that your connection or encoder can sustain it. Plan for reliable upstream capacity beyond the video rate, include audio and normal network variation, then test under realistic conditions.
Why use -re with a video file?
It asks FFmpeg to read the file in real time, which is useful when sending a file as a live feed rather than letting it run through as quickly as possible. The right command still depends on the input, build, output format and current ingest details.
Does the example work unchanged on every Ubuntu 24.04 system?
No. FFmpeg versions, build options, encoder availability, drivers, file streams and YouTube event settings vary. Check the installed encoders, adapt the command to the source, protect the stream key and test the incoming stream before relying on it.