For a suitable local 3840×2160, 60 fps SDR video with audio, FFmpeg can loop the file and send an H.264 stream to YouTube Live using an NVIDIA GPU encoder. The command below is a starting template: it does not upscale or convert arbitrary media to 4K60, and it still needs checking against your file, GPU, FFmpeg build and network.
The key choices are real-time file pacing, an infinite input loop, explicit stream mapping, H.264 NVENC at a constant bitrate, and RTMPS output. YouTube’s current encoder guidance lists 50 Mbps for H.264 at 2160p60; check the official page again before a live run because recommendations can change.
Check that the input is suitable 4K60 SDR video
The output settings do not make a source into 4K60. They tell the encoder how to encode what it receives. If the file is 1080p, 30 fps, HDR, variable-frame-rate, or missing audio, this command will not automatically turn it into a correctly prepared 3840×2160, 60 fps SDR programme. Scaling, frame-rate conversion, tone mapping and colour handling require deliberate filter and metadata choices, which are outside this simple loop template.
Before sending anything live, inspect the actual file with a media probe. Check its width and height, frame rate, pixel format, colour characteristics, duration and stream list. For a typical SDR H.264 path, confirm that the source is progressive 3840×2160 at 60 fps and that its colour information is appropriate for SDR Rec. 709. Do not assume that a filename containing “4K” or “60fps” proves those properties.
Audio deserves the same check. Confirm that the file has an audio stream, and note whether it is stereo, its sample rate, and whether the sound is present throughout. If it contains several language tracks or commentary tracks, blindly choosing the first one may select the wrong programme audio. If there is no audio, the optional mapping in the example below lets FFmpeg proceed without a first audio stream; it does not create silence or repair an absent track.
A one-file loop repeats the end of the file by returning to its beginning. If the last image or sound does not join the first, viewers may notice a jump, click, pause or abrupt change at every boundary. Listen and watch across the end-to-start transition before treating the file as suitable for continuous playback. For a devotional channel, for example, a sudden cut between the final chant and the opening silence may be more distracting than a modest bitrate difference.
For context on why a prepared file is not the same thing as a live encoder configuration, see our guide to YouTube Live settings for pre-recorded 1080p content. The resolution and frame rate differ, but the practical lesson is the same: check what the source contains before selecting output settings.
Put loop and realtime options before the input
Here is the complete starting command for the stated case:
ffmpeg -re -stream_loop -1 -i "input.mp4" \\
-map 0:v:0 -map 0:a:0? \\
-c:v h264_nvenc -preset p5 -rc cbr \\
-b:v 50M -maxrate 50M -bufsize 100M \\
-g 120 -bf 2 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://YOUR_INGEST_URL/YOUR_STREAM_KEY"
Replace input.mp4 with the path to your local file. The backslashes continue a command across lines in a Unix-style shell; on Windows, use the continuation syntax for your shell or put the command on one line. Keep the input path quoted when it contains spaces. The command uses FFmpeg’s documented input and output option model; consult the FFmpeg documentation when adapting options to a different source or build.
The position of -re and -stream_loop -1 is deliberate. They are input options and belong before the relevant -i. -stream_loop -1 asks FFmpeg to loop the input indefinitely. -re reads a file at its native rate rather than consuming it as quickly as the computer can decode and encode it. Without pacing, a file may be processed faster than real time, which is not the intended behaviour for a live broadcast.
This pacing advice is for file input. It should not be copied mechanically to a camera or another already-live capture source: rate-limiting an actual live input can lead to packet loss. If the source is not a local file, reconsider the input path and timing options rather than assuming this template applies unchanged.
The command processes one input. If you add more inputs, each input has its own options and mapping decisions, and option placement becomes more significant. Keep the loop and realtime flags immediately before the file’s -i so that they clearly apply to that file, not to an output or an unrelated input.
Map the video and optional audio streams
-map 0:v:0 selects the first video stream from input zero. -map 0:a:0? selects the first audio stream from that same input if it exists. The question mark makes that audio mapping optional, so a video-only file does not fail simply because there is no first audio stream to select.
That concise mapping is useful only when it matches the file. If the file has several audio streams, inspect them and select the intended one. If the video is not the first video stream, revise the mapping. Mapping is not a quality setting; it decides which existing streams are sent to the output. It also does not mix multiple tracks together or fix sync problems.
If you do need to change mappings, test the resulting output with the exact media file. A common failure is a command that encodes successfully but sends the wrong language or no sound because its stream assumption was false. Our guide on streaming podcast MP3 files with FFmpeg covers a different source format, but its attention to audio selection is relevant when you adapt this command.
If sound and picture drift apart, do not treat a larger video bitrate as the cure. Check source timestamps, selected streams and the encoded test output. You can use the practical checks in our guide to audio and video sync on a 24/7 YouTube stream when the issue appears during a longer run.
Configure NVENC video and AAC audio
-c:v h264_nvenc selects FFmpeg’s H.264 encoder through NVIDIA’s NVENC hardware encoding support. It only works where the installed FFmpeg build exposes that encoder and the available NVIDIA GPU supports the chosen format and workload. NVIDIA documents the encoder and its hardware-dependent capabilities in its NVENC application note. A recognised encoder name alone does not establish that a particular GPU can sustain this 4K60 job continuously.
The template uses -preset p5, -rc cbr, and a 50 Mbps target and maximum video rate. These settings are intended as a starting point for H.264 2160p60 ingest, not as a universal quality or performance guarantee. YouTube Help lists 50 Mbps as its recommended H.264 bitrate for 2160p60 and recommends constant bitrate encoding. The -bufsize 100M is part of this rate-control configuration; it is not extra upload bandwidth and should not be read as a guarantee of a particular delay or visual result.
The group-of-pictures setting is -g 120. At 60 frames per second, 120 frames correspond to two seconds. YouTube recommends a two-second keyframe interval and says not to exceed four seconds. The command also sets -bf 2, matching YouTube’s listed advanced setting of two B-frames. Frame pacing or source characteristics can affect the actual encoded stream, so verify the result rather than inferring it from the command alone.
For audio, -c:a aac -b:a 128k -ar 44100 encodes the selected audio as AAC at 128 Kbps and 44.1 kHz. YouTube lists AAC or MP3 as acceptable audio codecs and recommends 128 Kbps stereo audio at 44.1 kHz. This command does not force stereo channel layout; if the source is multichannel or has an unexpected layout, inspect it and decide whether an explicit channel-layout conversion is needed.
HEVC or AV1 can change the bitrate and hardware requirements, and HDR needs a different path. YouTube lists 35 Mbps for HEVC or AV1 at 2160p60, while its HDR guidance calls for HEVC over RTMP(S), 10-bit HDR and appropriate colour metadata. Do not swap the codec name in this SDR command and assume HDR is preserved correctly. Check YouTube’s current encoder recommendations and NVIDIA’s FFmpeg guide, then confirm that your GPU and build support the intended codec, profile, bit depth and dimensions.
| Choice in this template | What it means | Check before relying on it |
|---|---|---|
| H.264 with NVENC | Hardware H.264 encoding through supported NVIDIA hardware | Verify GPU capability and FFmpeg encoder availability |
| 50 Mbps video, CBR | Matches YouTube’s listed H.264 recommendation for 2160p60 | Provide stable upload capacity above the total stream rate |
| AAC at 128 Kbps, 44.1 kHz | Encodes the mapped audio stream using the listed stereo recommendation | Check channel layout and listen to the output |
| 120-frame GOP | Two seconds when the stream is 60 fps | Check the actual output and source frame rate |
Set the output format and YouTube RTMPS destination
-f flv selects the FLV output container used for this RTMP-family live stream. The final argument is a destination placeholder, not a usable address: replace it with the ingest address and stream key shown for your broadcast in YouTube Live Control Room. YouTube recommends RTMPS, a secure extension to RTMP, for live ingest. Use the current endpoint supplied for your stream rather than copying an address from an old command or another channel.
The placeholders are shown together to make the command readable, but the exact combined address format depends on the ingest details YouTube provides. Do not include the literal words YOUR_INGEST_URL or YOUR_STREAM_KEY. If the destination is malformed, or the key belongs to another live setup, the encoder may fail to connect or send to the wrong broadcast. Keep the endpoint and key as separate pieces while preparing the command, then assemble them only as required by the destination format YouTube gives you.
YouTube’s live encoder guidance also notes that 2160 streams use normal latency because its low-latency option is unavailable at that resolution. If your programme needs immediate audience interaction, consider whether 4K delivery is more important than latency before committing to this format. Resolution, bitrate, latency and viewer connection conditions are related choices, not switches that all move in the same direction.
A stable network must carry the video bitrate, audio and transport overhead with headroom. The recommended video rate is not the complete network requirement. If your upload is inconsistent, lowering a command’s nominal bitrate may not fix congestion or interruptions; first establish what the connection can sustain and test at the intended time and location. Our article on preventing buffering in a 24/7 worship stream discusses the broader stream-health side of that decision.
Protect the key and validate before relying on the run
Treat the stream key as a credential. Anyone who obtains it may be able to send video to the associated broadcast, so do not paste it into a public post, share it in a screenshot, or commit a command containing it to a public code repository. Avoid leaving it in shell history or logs that other people can read. If you think it has been exposed, use YouTube Live Control Room to manage or replace the key, then update your command.
You can avoid putting a key directly into a command that may be saved or shared by using your shell’s environment variables or another private configuration method. The exact syntax varies by operating system and shell; take care that the expanded value does not appear in a debug log or screen recording. Do not ask someone to troubleshoot a redacted command by sending the unredacted key. Share the non-secret parts and the error text instead.
Before a scheduled broadcast, confirm that h264_nvenc is available in your FFmpeg build. The command ffmpeg -h encoder=h264_nvenc can show the encoder options exposed by that build, but it does not prove sustained real-time performance. Check the exact GPU and supported input format, then run a representative test long enough to expose issues that a brief launch check might miss. NVIDIA’s guide describes FFmpeg/NVENC configuration, but capabilities depend on the hardware and software combination you actually have.
Start a private or otherwise suitable test broadcast in YouTube Live Control Room. YouTube recommends testing with representative audio and video movement and monitoring stream health. Watch for motion quality, dropped or unstable output indications, correct audio, and the file’s loop boundary. A static picture can conceal encoding or motion issues, while silence can hide a mapping mistake. Review both the local encoder output and YouTube’s health information; neither alone proves every part of the path is satisfactory.
If the connection fails, work through the components rather than changing several settings at once. Confirm the RTMPS endpoint and key, outbound connectivity, network stability, encoder initialisation, mapped audio stream, and source timestamps and formats. These are sensible diagnostic checks, not claims that any one fault is responsible. Keep a known-good copy of the command with the secret removed so that changes can be compared and reversed.
For an unattended channel, the local command also implies that the computer and network must remain available, and that someone should notice a failure. If you do not want the broadcast to depend on a home or office computer staying on, StreamNeo removes that specific always-on-computer burden by turning an uploaded video into a YouTube live stream that can continue with your computer switched off. It is YouTube-only, so it is not a fit if you need to publish to another platform as part of the same workflow.
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
Does this command make any video 4K at 60 fps?
No. It assumes the input is already suitable 3840×2160, 60 fps SDR video. A different source may need explicit scaling, frame-rate conversion or colour processing, and those choices are not included here.
Can I use the command without an NVIDIA GPU?
Not as written, because h264_nvenc selects NVIDIA hardware encoding. Check the installed FFmpeg build and the GPU’s capabilities; otherwise choose an encoder available in your environment and review its performance and YouTube-compatible settings.
Why are -re and -stream_loop -1 before -i?
They apply to the file input: -re paces reading at the source rate, and -stream_loop -1 repeats the input indefinitely. Do not apply the file-pacing advice blindly to a live capture source.
What should I do if YouTube does not receive the stream?
Check the current RTMPS endpoint and key, then confirm connectivity, NVENC availability, stream mapping and source compatibility. Run a test broadcast and use YouTube’s stream-health information before relying on the setup unattended.