A local 4K video does not become a live broadcast merely because FFmpeg can read it. FFmpeg must pace the file in real time, encode and package it for delivery, and send it to the destination and stream key supplied by YouTube Live Control Room.
The dependable approach is to inspect the source and your FFmpeg build first, choose a bitrate that matches the codec, then run a private or unlisted test while checking YouTube’s preview and stream health. The steps below are a configuration guide, not a claim that one Ubuntu release, computer or Indian ISP has been tested.
Prepare the local 4K60 source file
Start with the file, not the streaming command. A filename containing “4K 60” does not prove that the media is 3840 by 2160 pixels or has a 60 fps video track. Inspect its streams with ffprobe, which is installed alongside FFmpeg in many packages but may need to be installed separately:
ffprobe -hide_banner -i "/path/to/video.mp4"
Look for the video codec, dimensions, reported frame rate, pixel format and duration, as well as whether there is an audio stream. ffprobe output can distinguish a source that really has a 60 fps track from one that is lower-rate or variable-rate. If the file has no audio, do not assume that an audio option in a sample command will create a meaningful soundtrack. If the source contains several audio or subtitle tracks, decide which streams you intend to send.
Check that the file can be read through its entire duration, and make sure its location and permissions will remain available while the broadcast runs. Keep a copy of the original. If you need to trim, scale, change frame rate or repair audio, make that a deliberate preparation step and review the result before using it as a live source. Frame-rate conversion cannot recover motion detail that was never captured in the original.
A long file also needs enough local storage and a playback path that will not be interrupted by a desktop sleep setting, external drive disconnect or a process that closes when you log out. Those are operational risks separate from the stream itself. For a 24/7 channel that schedules multiple files, a rotation plan matters too; see this guide to scheduling a continuous stream of ambient videos.
Create the YouTube Live stream and obtain its destination and key
Before investigating FFmpeg errors, confirm that your channel can go live. YouTube’s eligibility guidance says live streaming requires channel verification and no live-streaming restrictions in the preceding 90 days; it also states a minimum age of 16. Check the current YouTube live streaming eligibility requirements for the channel, because a channel-side restriction cannot be fixed by changing encoder flags.
In Live Control Room, create or schedule the broadcast and open Stream settings. Copy the RTMPS destination URL and the stream key associated with that stream. The destination tells the encoder where to send media; the key identifies which stream it should enter. They are related but distinct values, and a URL from one stream combined with another stream’s key can lead to a connection failure.
Use RTMPS when that is the destination YouTube provides. RTMPS is RTMP protected by TLS/SSL. YouTube’s RTMPS guidance explains where to obtain the server URL and key and says to try port 443 if an otherwise-correct URL produces an SSL error. Do not substitute a guessed endpoint for the value shown in your own Control Room.
Treat the key like a password. Do not publish it in a script, screenshot, article, shell history or support post. Avoid pasting it into a command that will be shared or recorded in terminal history. If you share FFmpeg logs to diagnose a problem, first check that neither the key nor a full destination containing it is visible. If a key is exposed, replace it through the stream settings before using that stream again.
Choose FFmpeg encoding and pacing
FFmpeg has separate jobs in this workflow: it reads the file at a live rate, encodes or copies the media as appropriate, and muxes the audio and video for delivery. YouTube supplies the destination and secret key. Neither service can make the other part correct automatically: a valid key will not fix an encoder that cannot keep up, and a well-encoded file cannot reach the right broadcast without the matching destination.
For a file input, FFmpeg’s -re option reads at the native frame rate rather than as fast as the machine can process the file. Its command-line documentation describes it as equivalent to -readrate 1 and notes its usefulness when streaming from a file. -stream_loop -1 tells FFmpeg to repeat an input indefinitely. Both are input options, so put them before that input’s -i. See the FFmpeg command-line documentation for option placement and behaviour.
The following is an illustrative H.264 starting pattern, not verified working code for every Ubuntu package or source file. Replace the file path and both placeholders using your own inspected media and the values in Live Control Room. Never put a real key in a public example:
ffmpeg -re -stream_loop -1 -i "/path/to/video.mp4" \\
-c:v libx264 -preset veryfast -b:v 50M -maxrate 50M -bufsize 100M \\
-r 60 -g 120 -keyint_min 120 -sc_threshold 0 \\
-pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://<URL-FROM-YOUTUBE-LIVE-CONTROL-ROOM>/<STREAM-KEY>"
The values shown are connected to an H.264 4K60 example, not a universal profile. Confirm that your installed FFmpeg build includes libx264 and can use the RTMPS/TLS output it needs. A packaged build may differ by Ubuntu release or installation source. You can inspect available encoders with ffmpeg -encoders; if a requested encoder is absent, choose an available supported encoder or install a build that includes it before planning a test.
The command also assumes the input’s dimensions and streams are suitable. If it lacks audio, has multiple tracks, uses an unsuitable pixel format, or is not actually 4K60, you may need explicit stream mapping, conversion or different audio handling. Do not add scaling and frame-rate conversion blindly: each can alter the output and consume more processing. For a useful background on isolating connection and media-format problems, consult common causes of YouTube rejecting an FFmpeg stream.
Match bitrate to the selected codec
YouTube’s current encoder guidance gives different 2160p60 targets by codec. For H.264, the recommended video bitrate is 50 Mbps and the listed minimum is 14 Mbps. For AV1 or H.265/HEVC, the recommended target is 35 Mbps and the listed minimum is 10 Mbps. These are YouTube-published settings, not a promise that an Ubuntu encoder, local network or audience playback device will handle a particular stream well. Check the current codec and resolution table before going live, in case the guidance changes.
| 2160p at 60 fps choice | YouTube-listed minimum video bitrate | YouTube-recommended video bitrate | Practical check |
|---|---|---|---|
| H.264 | 14 Mbps | 50 Mbps | Confirm libx264 or another selected H.264 encoder is available and can encode in real time. |
| AV1 or H.265/HEVC | 10 Mbps | 35 Mbps | Confirm the exact encoder is present and that the machine can sustain its workload. |
Do not set H.264 to 35 Mbps because that is the AV1/H.265 recommendation. A lower bitrate than the recommended target can mean less room for detail in fast movement, while raising bitrate increases the upload burden. Choose the row for the codec you actually send, then assess a representative test rather than treating a minimum as the quality target.
Some FFmpeg builds can encode H.264 but not AV1 or H.265, and availability alone does not establish real-time performance. Encoder requirements vary with software, hardware, preset and source. A faster preset may reduce the encoding workload but can affect compression efficiency; hardware encoding may be useful where available, but its presence and capabilities are machine-specific. Test the actual choice on the intended machine instead of inferring capacity from the codec name.
Configure keyframes and real-time delivery
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. At 60 frames per second, two seconds corresponds to 120 frames, which is why the illustrative command uses -g 120. Its keyframe settings need to agree with the output cadence; they are not simply a quality slider. YouTube also lists constant bitrate (CBR) for live encoder settings. In the example, -b:v and -maxrate express a target and cap, while -bufsize affects rate control. Check the behaviour of your selected encoder and current YouTube guidance rather than assuming every encoder interprets options identically.
For audio, YouTube lists AAC or MP3, and recommends 44.1 kHz and 128 kbps for stereo. The example uses AAC at those values. If the source audio has a different channel layout or sample rate, listen to the converted test output. If there is no audio track, decide whether silence is appropriate or whether to omit audio options; an option cannot create the intended programme sound.
-re controls the rate at which the input file is read; it does not guarantee the encoder will finish each frame on time. Watch FFmpeg’s progress and output for signs of falling behind, and test with the most demanding movement in the file. If the process cannot encode at the required pace, changing the bitrate alone may not solve the problem. You may need another preset, an available hardware encoder, a prepared lower-complexity file or different equipment.
If you want the same file to repeat, -stream_loop -1 keeps the input looping. Listen and watch at the file boundary: a cut, silence or sudden visual jump may be unsuitable for an uninterrupted channel even though the process continues. If instead you are building a channel around a rotation of music and still images, a rotating visual for a YouTube radio stream is a different production choice from repeatedly looping one 4K video.
Check upload capacity and machine performance
Measure upload, not download. A speed test that reports a high download rate does not show that your connection can send a live stream. YouTube advises that the total outgoing bitrate must fit available upload bandwidth and recommends 20% headroom. For the 50 Mbps H.264 video target, planning with that headroom means 60 Mbps of sustained available upload for the video arithmetic, with additional allowance for audio and any other outbound traffic. The 60 Mbps figure is calculated from YouTube’s target and headroom guidance; it is not a separate platform benchmark.
Measure under conditions resembling the planned broadcast, including the time of day and other devices or workloads that will share the connection. An India-based viewer has no special bitrate exemption: actual capacity varies by ISP, location, congestion, routing and home network. A short peak reading is not evidence of stable capacity through an overnight stream. If you cannot maintain the selected bitrate plus headroom, choose a realistic codec or output profile and test it; do not assume an ISP plan’s advertised rate is the sustained upload you will have.
The Ubuntu computer also has to read, encode and send continuously. During a representative test, watch CPU use, memory, disk access and FFmpeg’s reported progress. A source stored on a slow or unreliable external drive can interrupt input; an encoder that cannot keep pace can drop or delay frames even when upload is available. Keep the machine awake, avoid scheduled restarts or updates during the broadcast, and use a wired network connection where practical to remove one source of wireless variability. None of these precautions guarantees a stable stream, so monitor rather than relying on a one-time check.
If you have concluded that maintaining an Ubuntu machine and its connection is the wrong operating model for your channel, a hosted path may remove the need to keep your own computer running: StreamNeo takes an uploaded video and broadcasts it to YouTube, which can be useful when local power or overnight supervision is the recurring pain. It is YouTube-only, so it does not replace this FFmpeg workflow for other destinations.
Start a test stream and verify Control Room health
Do not make the first run a public overnight broadcast. Use a private or unlisted test where suitable, with a portion of the actual source that includes motion, transitions and representative audio. Confirm that the preview appears in Live Control Room, the selected resolution and frame rate are appropriate, audio is audible, and the stream health indicators do not show a continuing issue. YouTube’s live streaming tips recommend testing and monitoring stream health.
For a 4K stream, plan for normal latency. YouTube says the low-latency improvement option is unavailable at 4K/2160 and streams are set to normal latency. That affects how quickly the audience sees the programme, not whether FFmpeg can pace the file. Set expectations accordingly if you are reading chat or coordinating a live response around prerecorded material.
If the connection fails, check the simplest distinctions first: is the URL copied from this stream’s settings, is it RTMPS, and does the key belong to that same stream? For an SSL error, consult YouTube’s port 443 guidance. If the destination is accepted but the picture or sound is wrong, review source streams, mappings, codec availability and the chosen rate-control settings instead of repeatedly changing the key. Keep logs private until you have removed secrets.
Once the test is stable, make a short operational checklist: the source path, selected codec and bitrate, keyframe cadence, stream settings location, machine power settings and who will monitor Control Room. Save a command template with placeholders rather than a secret key. A channel intended to run through the night needs a recovery and supervision plan; an initially healthy preview is not a guarantee that a later network or process interruption will be recovered automatically.
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
How do I loop a video file to YouTube Live with FFmpeg?
Put -re -stream_loop -1 before the input’s -i so FFmpeg reads it in real time and repeats it. Pair that input handling with an output codec and bitrate suited to YouTube’s current settings, and test the loop boundary for an audible or visible interruption.
What bitrate do I need for 4K 60fps YouTube Live?
YouTube’s current guidance lists 50 Mbps recommended and 14 Mbps minimum for H.264 at 2160p60. It lists 35 Mbps recommended and 10 Mbps minimum for AV1 or H.265/HEVC; select the figures for the codec actually being encoded and leave upload headroom.
How much upload speed do I need to stream 4K from India?
Use sustained available upload, not download speed, and plan for YouTube’s recommended 20% headroom above the total outgoing bitrate. For a 50 Mbps H.264 video target, that works out to 60 Mbps before any extra outbound traffic; your actual connection depends on provider, location, congestion and routing.
Why is my 4K stream not low latency?
YouTube does not offer its low-latency option for 4K/2160 streams, which are set to normal latency. Test in Live Control Room and account for that delay if viewers need a quick response.