To stream a prerecorded 4K video as a YouTube Live broadcast, FFmpeg must read the file repeatedly and send its video and audio to YouTube’s live ingest endpoint in real time. The loop is created by your outgoing encoder feed; uploading a video normally does not turn it into a live stream.
The command below is a starting point for a 4K, 30 fps, SDR file encoded as H.264 with AAC audio. Treat it as a configuration to inspect and test, not a guarantee that a particular computer, connection or file can sustain 4K output. YouTube’s encoder settings are the reference for current ingest recommendations.
Prepare the prerecorded 4K file
Start with a file whose resolution, frame rate, audio and colour characteristics you understand. “4K” is often used to mean 2160p, but two files at that resolution can differ in frame rate, codec, bitrate, colour range and HDR status. Those details affect what FFmpeg needs to encode and what YouTube receives.
Inspect the file before building the command. FFmpeg’s ffprobe tool, commonly installed with FFmpeg, can report stream properties. For example:
ffprobe -hide_banner "input.mp4"
Look for the video codec, dimensions, frame rate, pixel format and audio codec. A 3840-by-2160 file at 30 fps is not the same workload as one at 60 fps. Check that the video plays from beginning to end, that the audio is present and synchronised, and that there are no accidental blank sections or unwanted material at the start or end.
If the source is HDR, do not assume that an SDR command will preserve its intended appearance. YouTube’s current encoder guidance lists codec options by use case and recommends H.265 for HDR; it says AV1 is not supported for HDR. If you do not know whether the source is HDR, establish that before adding colour conversion or metadata options. Unnecessary conversion can alter how the picture looks.
Also consider the content rights and channel purpose before making an old recording continuous. A meditation, devotional programme, lofi visual or local information loop can have a natural repeat point; a spoken programme may have an abrupt transition that becomes distracting over time. For channel-specific considerations around repeating audio, see whether podcasters can loop old episodes on a YouTube Live stream. That is a separate editorial decision from the FFmpeg settings.
Set up an encoder-based YouTube Live stream
In YouTube Studio, create or schedule a live stream and choose the encoder workflow. The YouTube guide to creating a live stream with an encoder explains where the stream URL and stream key are provided. The URL identifies the ingest destination; the key identifies your broadcast to YouTube.
Treat the stream key like a password. Do not put it in a public document, screenshot, terminal recording or example that you intend to share. Anyone with access to a usable key may be able to send a feed to your event. If it is exposed, reset it in YouTube Studio and update the encoder command. Avoid saving a command containing the key in a shared script or a repository that other people can read.
For a scheduled stream, configure the event in advance and keep the Live Control Room open. Starting FFmpeg sends the encoder feed, but it does not necessarily make the event publicly live by itself. YouTube’s workflow provides a preview; you check that feed and then select Go live when you are ready. Keep the difference clear: FFmpeg supplies the outgoing live signal, while YouTube Studio controls the event and its audience visibility.
A file loop is useful for a fixed programme that should repeat, but it is not a substitute for a live production when viewers expect current information, interaction or a presenter. If your stream includes worship or a service with people and microphones, the planning needs are different from a file-only loop; the guide to live streaming worship services covers that broader production context.
Put -stream_loop -1 before the input
FFmpeg’s -stream_loop option controls how many times an input is read. A value of -1 means repeat indefinitely. It must be placed before the -i that names the file, because it is an input option and applies to the following input.
-stream_loop -1 -i "input.mp4"
Putting the option after the input does not express the same input configuration. If you later add other inputs, such as a separate audio file, take care that each input option is positioned for the input it is meant to affect. For this basic example there is one input, so the placement is straightforward.
Infinite looping means FFmpeg will keep reading the file until the process is stopped or fails. It does not make the transition between the end and beginning seamless. If the first frame and final frame do not match, viewers may see a jump; if audio ends abruptly, they may hear a click or silence before the next pass. Edit or prepare the file so its repeat point is acceptable before relying on the encoder to repeat it.
The FFmpeg command documentation describes input options and looping. Read the documentation for the version installed on your system if its behaviour or available encoders differ from the assumptions here. A managed workflow may be preferable when keeping a computer available and supervising a command overnight is the main obstacle: StreamNeo turns an uploaded file into a YouTube live feed, so the broadcast can continue without your own computer running.
Pace file playback with -re
A media file can usually be read faster than its playback duration. For a live broadcast, FFmpeg must not send the entire file to YouTube as quickly as the computer can decode it. The -re option reads the input at its native rate, pacing the file as if it were being read live.
For this use, place -re before -i as well:
-stream_loop -1 -re -i "input.mp4"
Looping and pacing solve different problems. -stream_loop -1 asks FFmpeg to keep returning to the file. -re controls the rate at which the file is read. Without pacing, the loop option alone does not make the outgoing feed behave like real-time playback.
Pacing at the source file’s native rate also means the input frame rate matters. If the file is 30 fps, this setting does not turn it into 60 fps. Do not add frame-rate conversion simply because the output is intended to be live. First decide whether a conversion is needed for compatibility or production reasons, then account for the extra processing and check the result in preview.
When you run the command, observe whether FFmpeg can keep pace without persistent errors or accumulating delay. The fact that a file plays smoothly in a desktop media player does not establish that it can be encoded and sent continuously at 4K. Encoding load and network conditions add work that ordinary playback does not.
Choose RTMPS and encoder output settings
YouTube recommends RTMPS, a secure extension to RTMP, for encoder ingest. The output format in this example is FLV, which FFmpeg uses for the RTMP-family output pattern. Follow YouTube’s current ingest URL and settings; do not substitute a guessed destination. The URL and key come from the Live Control Room, and together they form the destination used by the encoder.
Here is an illustrative command for a 4K, 30 fps SDR input using H.264 and AAC. Replace the input path and destination with your own values, and keep the key private:
ffmpeg \\
-stream_loop -1 -re -i "input.mp4" \\
-c:v libx264 -preset veryfast \\
-b:v 42M -maxrate 42M -bufsize 84M \\
-g 60 \\
-c:a aac -b:a 128k \\
-f flv "rtmps://SERVER/APP/STREAM_KEY"
This is not a tested universal command. It assumes FFmpeg was built with libx264, that the source and output are appropriate for this SDR workflow, and that the output is 30 fps. The -g 60 value corresponds to a two-second keyframe interval only at 30 frames per second. For a different frame rate, set the GOP size so the interval is approximately two seconds. YouTube recommends a two-second keyframe interval and says not to exceed four seconds.
YouTube’s recommended ingest bitrate depends on codec and frame rate. Its encoder settings page, checked in October 2026, lists these 2160p targets:
| Output | AV1 or H.265 | H.264 |
|---|---|---|
| 30 fps | 30 Mbps | 42 Mbps |
| 60 fps | 35 Mbps | 50 Mbps |
These are YouTube ingest recommendations, not a promise about the resolution each viewer will receive. YouTube processes the incoming feed into outputs, and playback resolution depends on its processing as well as the viewer’s device and connection. The loop itself does not call for a special bitrate; choose settings based on the actual codec, frame rate and YouTube guidance.
The example uses H.264 at 30 fps with -b:v and -maxrate set to the listed target, and a buffer setting twice that value. These are illustrative encoder parameters, not a guarantee of constant behaviour on every FFmpeg build. YouTube recommends CBR; check the encoder’s behaviour and the output shown in Live Control Room rather than assuming that a command line alone proves compliance.
You can use another codec only if your FFmpeg build supports it and the source, frame rate and ingest requirements suit it. Check available encoders with ffmpeg -encoders. Do not switch to H.265 or AV1 simply because their listed target is lower: encoding support, quality, HDR needs and compute capacity all matter. YouTube’s guidance should be consulted for the exact intended format.
If the source streams are already compatible, FFmpeg can copy them rather than re-encode them, which may reduce processor demand. But stream copying cannot change the encoded bitrate or keyframe spacing, and a source that plays locally is not necessarily suitable for YouTube ingest unchanged. The FFmpeg documentation describes copy as copying streams without re-encoding. Use it only after checking the source’s properties and the preview; otherwise encode to a deliberate output profile.
Finally, 4K output is a sustained workload. Before committing to a long broadcast, test the actual machine and connection with representative content. A speed test is a useful check, but do not treat a single result as proof that upload capacity will remain available throughout the stream. Leave practical headroom for other traffic and watch for drops or encoder overload. For the related question of uploading large video files from India, distinguish the one-time file upload from the ongoing upload of a live feed.
Check the Live Control Room preview
Start the encoder while the scheduled event is still in its setup stage. In the Live Control Room, wait for the incoming preview and inspect both picture and sound before selecting Go live. If the preview remains blank or reports a problem, do not assume the audience view will fix it. Check the destination, key, command output, stream health indicators and whether the encoder is still running.
Look for the details that are easy to miss in a short test: the image is actually 2160p if that is your aim, motion is not visibly stuttering, audio is present and in sync, and the loop transition is tolerable. Confirm that the broadcast is using the intended frame rate and that no unexpected crop or colour change has occurred. The YouTube page on managing live stream settings explains stream controls and latency choices.
Do not promise yourself 4K delivery to every viewer based on an encoder preview. The preview confirms that YouTube is receiving a feed; it does not control the quality selected by a viewer’s device or network. YouTube also notes that low-latency optimisation is not available for 4K/2160p, so plan for normal latency rather than designing a 4K event around a low-latency setting.
Keep the key private while troubleshooting. If you need to share logs or command output with someone helping you, remove the destination string first. A key displayed in a screenshot or copied into a public support post should be considered exposed and reset before the next broadcast.
Test the loop before the broadcast
Run a test long enough to observe more than the opening moments. Include representative movement and audio, as YouTube’s encoder guidance specifically advises testing with content similar to the actual stream. For a static devotional image, that might mean verifying the subtle animation or song transitions that recur; for a local news loop, check the captions and scene changes that viewers will see throughout the cycle.
A practical test has several separate questions. Does the file restart at the intended point? Does audio restart cleanly? Does FFmpeg maintain real-time output? Does the Live Control Room show a healthy incoming stream? Does the computer remain responsive while encoding? Does the connection cope when other normal household or business use is present? Record what you observe, then change one setting at a time so that a later improvement or problem has a likely cause.
For 4K, test at the intended resolution and frame rate, not merely at a reduced preview setting. If the encoder struggles, consider whether 30 fps is sufficient for the content, whether a supported hardware encoder is available, or whether a lower resolution better fits the machine and connection. YouTube’s recommended bitrate is not an instruction to force a setting a system cannot sustain.
A file-only broadcast also needs a plan for what happens if the process or connection stops. Decide who will notice, how the encoder will be restarted, and whether the event should be ended or resumed. If you want an always-on channel but cannot leave a computer running and monitored, that operational requirement is different from proving an FFmpeg command in a short test. For a discussion of what VPS specifications an always-on YouTube stream needs, compare the trade-offs before choosing a host or machine.
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 on YouTube Live?
YouTube does not turn a normal video upload into a live loop. Use an encoder such as FFmpeg to repeatedly read the file with -stream_loop -1, pace it with -re, and send the resulting feed to the live ingest destination provided in YouTube Studio.
Can I use this command for a 4K 60 fps file?
Not unchanged. The sample command assumes 30 fps, and its GOP value of 60 means two seconds only at that frame rate. Choose a suitable codec and bitrate using YouTube’s current encoder guidance, adjust the keyframe interval for the output frame rate, and test whether the encoding system and connection can sustain it.
Will everyone watching see 4K?
No command can guarantee that. The encoder sends a 4K feed to YouTube, but YouTube processes the stream into viewer options and actual playback depends on platform processing, device capability and connection conditions.
Is 4K low latency available for this loop?
YouTube’s encoder guidance says low-latency optimisation is unavailable for 4K/2160p. Plan for normal latency and check the current Live Control Room settings before the broadcast.