FFmpeg can send a local video file to YouTube Live at 3840×2160 and 60 frames per second, provided your computer can encode that output in real time and your upload connection has enough headroom. The command below is a starting template for a prerecorded file, not a universal drop-in command.
You will need to create or select the live event in YouTube Live Control Room, retrieve that event’s ingest URL and stream key, and test the preview before relying on the broadcast. YouTube’s current encoder guidance recommends 50 Mbps for H.264 at 2160p60, CBR, and a two-second keyframe interval.
What this command is designed to do
The example is designed for a local prerecorded file such as a devotional programme, ambience loop, news package or music visualiser. FFmpeg reads that file at its normal playback rate, converts or encodes it as necessary, and sends one video stream and an optional audio stream to YouTube over RTMPS.
This is different from capturing a camera or screen. The -re option is useful when a file is being used to simulate a live source because it prevents FFmpeg from reading the file as quickly as the computer allows. It should not be added casually to a real-time capture input, where throttling the input can cause packet loss. The FFmpeg documentation explains this distinction and the behaviour of the main command-line options.
Start with this H.264 template:
ffmpeg -re -i "input.mp4" \
-map 0:v:0 -map 0:a:0? \
-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://INGEST_URL/STREAM_KEY"
The file name, ingest URL and stream key are placeholders. Replace them only on your own computer. Do not paste a working key into a public article, screenshot, shared script, support ticket or log. A key grants access to the stream input, so reset it in Live Control Room if you believe it has been exposed. You can review YouTube’s live stream settings guidance for the current key-management controls.
This command assumes that your installed FFmpeg build includes the libx264 encoder, that the input has a usable video stream, and that the computer can produce 4K60 without falling behind. Those assumptions must be checked on your system. The command has not been presented as universally tested, and its flags do not guarantee continuous operation.
Prepare the file and the placeholders
Before changing bitrate settings, inspect the source. You need to know its dimensions, frame rate, pixel format, scan type, audio streams and duration. A file labelled “4K” may be 3840×2160, but it may also use a different frame rate, variable frame timing, HDR metadata or more than one audio track. Those details affect the output and the amount of work FFmpeg must do.
You can inspect a file with a command such as:
ffprobe -hide_banner "input.mp4"
ffprobe is distributed with many FFmpeg installations, but the exact output and available build options vary. Look for the video stream and note its resolution, frame rate and codec. Then check whether an audio stream exists. If the file has no audio, the optional audio mapping in the template will not create one; YouTube may still receive a video-only stream, but that may not suit your channel or programme.
Use a simple file path first. If the file is in the same folder as the terminal’s current working directory, input.mp4 is enough. Otherwise use the complete path and keep the quotation marks, particularly when a folder or file name contains spaces:
ffmpeg -re -i "/home/you/videos/night-loop.mp4" \
...
On Windows, a quoted path such as "C:\\Users\\You\\Videos\\night-loop.mp4" may be easier to manage, although shell quoting differs between Command Prompt, PowerShell and other terminals. The important point is to confirm the path locally rather than copying a path format from another operating system.
Create the YouTube event before you begin. In Live Control Room, use the stream’s encoder settings to obtain the current server or ingest URL and the stream key. YouTube recommends RTMPS for encoder ingestion, but the exact URL shown to you belongs to your event or account. The YouTube Live API documentation also describes ingestion addresses and stream-health information, but it does not give you a universal private key.
Keep the source representative of the real broadcast. A still image is not a useful test for a channel whose normal content contains fast movement, animated text or frequent scene changes. A devotional loop with album artwork, a local news sequence with tickers, and a nature video with water movement can place different demands on the encoder even when all three have the same dimensions.
If your file is not already 3840×2160, the example does not explicitly scale it. FFmpeg may encode it at its source dimensions while applying the requested frame rate, which is not the same as producing a genuine 4K output. Add a deliberate scaling and format filter only after deciding how you want to handle aspect ratio, cropping and quality. Enlarging a lower-resolution file does not restore detail.
Loop and pace a prerecorded file in real time
The -re option appears before the input in the example because it controls how FFmpeg reads the file. For a prerecorded source, this makes the file behave more like a live input instead of being consumed immediately. Without it, FFmpeg may process faster than real time, finish the file quickly and send data in bursts rather than maintaining the intended playback pace.
The command does not loop the file indefinitely. It reads the file once and exits at the end. For a single event, that may be what you want. For a continuous channel, use an input strategy that matches your content and verify the result in a test event before using it publicly.
One basic looping form is:
ffmpeg -stream_loop -1 -re -i "input.mp4" \
...
Here, -stream_loop -1 asks FFmpeg to repeat the input indefinitely. It is useful for a simple file loop, but the transition between the end and beginning can still be visible or audible. If the file contains a hard cut, a click, a black frame or a different audio level at its boundary, viewers will encounter that every time the loop turns over.
For several files, a concat workflow or a prepared longer programme may be more predictable than repeatedly opening one file. A playlist can also introduce different dimensions, frame rates, audio layouts or codecs, each of which may require normalisation before streaming. If your planned channel is a sequence of nature clips, the guide to looping a playlist of nature videos on YouTube Live covers the content-side planning that sits around the encoder command.
Do not use -re as a general cure for an overloaded live input. A camera, capture device or other genuine live source is already arriving in real time. Throttling it again can make FFmpeg read too slowly and lose packets. The safest approach is to decide first whether the input is a file being played back or an active capture source.
Pacing also does not solve encoding overload. If the computer cannot encode each 4K frame before the next one is due, FFmpeg may fall behind even though the file is being read at the correct rate. Watch the terminal output and the Live Control Room preview together during testing. A command that starts successfully can still become unsuitable when motion increases or when the system runs for longer.
Set 4K60 output, bitrate and keyframes
For conventional SDR H.264 at 2160p60, YouTube’s official encoder settings list 50 Mbps as the recommended video bitrate. The template therefore uses -b:v 50M, with matching -maxrate 50M and a -bufsize 100M example for a CBR-oriented configuration.
These values are YouTube recommendations, not a promise that your computer can encode at that rate or that your connection can sustain it. The video bitrate does not include audio or transport overhead. Your upload connection needs headroom above the video target, and YouTube advises testing the upload bitrate and choosing settings that remain reliable for the connection rather than selecting a number that only works in ideal conditions.
The command requests 60 output frames per second with -r 60. The GOP settings request a keyframe every 120 frames: at 60 frames per second, that represents two seconds. -keyint_min 120 sets the minimum interval, while -sc_threshold 0 prevents scene changes from causing the encoder to insert a different cadence in this particular template. Check the actual output and stream-health messages rather than treating flags as proof of the final result.
YouTube recommends a two-second keyframe interval and says it must not exceed four seconds. If you change the frame rate, you should reconsider the frame count used for the GOP. At a different cadence, 120 frames no longer represents two seconds. If you use a hardware encoder or another codec, its option names and rate-control behaviour may differ from libx264.
The veryfast preset is a starting point, not a quality or performance guarantee. A slower preset can spend more time compressing each frame, while a faster preset may reduce the work required at the cost of compression efficiency. At 4K60, the practical choice is the one that keeps up with the source and produces acceptable pictures on the particular processor or accelerator you are using.
YouTube’s current guidance also lists 35 Mbps for 2160p60 when using AV1 or H.265. A lower recommended video bitrate does not automatically make those codecs the better choice. Your FFmpeg build must include a suitable encoder, the encoder must run at 4K60 on your hardware, and the receiving workflow must support the codec you select. For HDR, YouTube recommends H.265 and states that AV1 is not supported for HDR. Confirm the current official requirements if HDR is part of the plan.
For a conventional SDR stream, YouTube recommends progressive video, square pixels, Rec. 709, 8-bit depth, and CBR. The template requests yuv420p, which is a common compatibility choice, but it does not set every colour property explicitly. If colour accuracy matters, inspect the source and decide whether you need explicit colour metadata rather than assuming FFmpeg will infer the intended values.
Map the video and optional audio
The mapping portion is deliberately explicit:
-map 0:v:0 -map 0:a:0?
The first expression selects the first video stream from the first input. The second selects the first audio stream, but the trailing ? makes that audio selection optional. This is useful when you want one command to work with files that sometimes contain audio and sometimes do not. FFmpeg’s documentation on stream selection and mapping explains the syntax and its consequences.
Explicit mapping is safer than allowing FFmpeg to guess when a file contains several video or audio streams. A file may include a commentary track, a second language, a silent proxy stream or embedded artwork. Selecting 0:a:0 means “the first audio stream”, not “the audio track you intended”. Inspect the file and change the mapping if the desired programme audio is elsewhere.
The audio options in the template request AAC at 128 kbps, sampled at 44.1 kHz:
-c:a aac -b:a 128k -ar 44100
YouTube lists AAC or MP3 audio, 44.1 kHz stereo audio and 128 kbps stereo audio among its recommended conventional settings. The command does not explicitly force stereo. If the source has an unusual channel layout, inspect the result and add an appropriate audio layout or channel mapping only when you understand what the source contains.
If your video has no audio and you want a silent track, that requires a separate input or a generated audio source. Do not assume the optional mapping creates silence. Conversely, if audio is essential for a devotional song, news bulletin or study stream, do not accept a successful video connection as proof that the audio is present. Listen to the unlisted preview and check the stream information.
Audio that begins later than the video, ends early or has a different duration can create a poor loop. For a long-running channel, check the start and end points as well as the content in the middle. A technically valid AAC stream can still contain an audible gap at every loop boundary.
Send the event URL and key over RTMPS
The final argument sends the multiplexed FLV output to the event’s RTMPS address:
-f flv "rtmps://INGEST_URL/STREAM_KEY"
RTMPS means RTMP carried over an encrypted SSL connection. YouTube recommends RTMPS for encoder ingestion. Replace the complete placeholder with the exact address and key shown in your Live Control Room. Do not invent a path, append a second key separator, or assume that an address copied from another event remains valid for this one.
Treat the URL and key as credentials. Avoid putting them in a publicly readable shell history, a shared document or a repository. If you need a repeatable launch process, use local permission controls and a private configuration method appropriate to your operating system. Never include the actual value when asking for help.
If the connection fails, separate authentication and encoding questions. First check that the event exists, the key is current, and the destination was copied accurately. Then check whether FFmpeg can open the input and whether the selected encoders are available. A message about an unknown encoder is a local FFmpeg issue, while a rejected connection can involve the event or ingest details.
RTMPS is not the same as HLS ingestion. YouTube’s HLS delivery guide describes a different workflow involving M2TS segments, AAC audio, closed GOP requirements and segment timing. HLS can be useful when an encoder specifically needs it, including some HDR workflows, but changing rtmps to another protocol in this command does not implement HLS. HLS is segment-based and usually has higher latency than RTMP- or WebRTC-based ingestion.
Protocol choice also affects the rest of your setup. If your encoder only supports HLS, follow YouTube’s HLS packaging rules. If your file-based workflow is built around an FLV output and an RTMPS destination, keep the RTMPS command separate and validate it as its own path. For a broader explanation of protocol trade-offs, see RTMP vs RTMPS vs SRT for always-on streams.
Test the preview before relying on it
Create an unlisted or test event and run the exact file, command and network connection you expect to use later. YouTube’s own guidance is direct: make sure to test before starting the live stream. Test with representative motion and audio, not only a static image, and leave the command running long enough to expose an encoding or connection problem.
Use Live Control Room as the authority for what YouTube receives. Confirm that the preview shows 3840×2160 if that is the intended output, that the frame rate is 60, and that sound is present when it should be. The YouTube Live API documentation documents stream-health concepts and messages, including diagnostics for low bitrate, frame-rate mismatch and keyframe or GOP issues.
A practical test sequence is:
- Confirm that the source file opens and has the expected video and audio streams.
- Start the command with the event unlisted or otherwise arranged for testing.
- Watch FFmpeg’s progress output for speed, frame count, duplication, dropping and errors.
- Check Live Control Room for resolution, frame rate, bitrate and stream-health messages.
- Watch a section with the same motion, overlays and audio complexity as the real programme.
- Stop the test, correct one issue at a time, and repeat it before making the event public.
The terminal’s reported speed is particularly useful. If it regularly falls below real time, the encoder is not keeping up with the file. Changing the bitrate alone may not solve that. You may need a different encoder, a faster preset, a smaller output, fewer filters or a machine with more encoding capacity. Hardware encoder names and options vary by build and system, so inspect the encoders installed locally instead of copying an option intended for another computer.
If YouTube reports a low bitrate, check the actual output and the network before assuming the target flag was applied. CBR settings shape the encoder’s behaviour but do not guarantee a constant network transfer rate. Leave upload headroom for audio, protocol overhead and ordinary variation in the connection.
If the frame rate is wrong, inspect both the input and output. A 30 fps source can be converted to 60 output frames, but repeated frames are not the same as new motion captured at 60 fps. If the source is variable-frame-rate, decide whether you need to normalise it before the live command. If keyframe messages appear, check the actual GOP cadence and the encoder-specific settings.
For a channel that must continue while your own computer is switched off, a file-based command running locally is not the only operating model. A remote managed workflow can remove the need to keep a personal computer awake, watch its temperature, reconnect manually and restart the command after a local interruption. StreamNeo is designed for the narrower case where you upload a video once, provide your own YouTube stream key, and need the broadcast to keep running with automatic monitoring and restart.
That convenience does not remove the need to check the source, rights, YouTube event settings or stream health. If your channel uses a local FFmpeg process, the FFmpeg VPS guide for 24/7 YouTube streaming in India may be more relevant when you want to manage the process yourself. The better choice depends on whether you need direct control over the command, access to particular encoders, and responsibility for keeping the machine and process operating.
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 on YouTube Live?
YouTube’s current encoder guidance recommends 50 Mbps for H.264 at 2160p60. It lists 35 Mbps for AV1 or H.265 at the same resolution and frame rate. These are recommended video bitrates, not a guarantee that your encoder or upload connection can sustain them, so test with headroom.
Does -re make FFmpeg loop a file forever?
No. -re paces a file at its native playback rate; it does not repeat the file. Add an appropriate looping method, such as -stream_loop -1, only when you have tested the loop boundary and the resulting long-running behaviour.
Can I use this command for a camera or capture card?
Not unchanged. The template is for a local prerecorded file, and -re is included to pace that file. A real-time capture input already arrives live, so applying a reduced read rate can cause packet loss; capture-device options and input formats also vary.
Is RTMPS the same as HLS ingestion?
No. RTMPS in this example sends an FLV stream to the event’s ingest address, while YouTube HLS ingestion uses a different segment and packaging workflow. HLS has its own M2TS, codec, AAC, closed-GOP and segment-duration requirements, so it should be configured from YouTube’s HLS documentation rather than substituted into this command.