You cannot use YouTube’s viewer-side playlist repeat control to create a live broadcast. For a continuous 4K60 stream, you need to loop your source files in a playback or FFmpeg workflow, then send the resulting feed to a YouTube Live event.
The practical setup has two separate parts: arrange the prerecorded videos in the order you want, including the repeat behaviour, and configure an encoder to deliver that continuous output. YouTube provides the live ingest settings, but it does not document a native playlist-to-live feature that performs the whole job for you.
Separate a YouTube playlist from a live source playlist
A YouTube playlist is primarily a viewer-facing list. Its repeat control tells YouTube’s player to play the items again for the person watching. It does not turn those items into one continuous live signal sent from your channel.
That distinction matters because a live encoder needs a source that is available continuously. The source might be one long video, a concatenated file, or a set of files handled by a playback application. The encoder then produces the video and audio signal that YouTube receives.
For a devotional channel, for example, you might arrange several 4K bhajan videos in a defined order and repeat them. For a study channel, you might use a long ambience file followed by several shorter scenes. The order and repeat setting belong to the playback stage, not to YouTube’s playlist page.
If you are deciding how to organise prerecorded material rather than configure FFmpeg directly, the workflow in how to create a 24/7 YouTube music stream with a playlist covers the wider planning problem. For this article, the important point is that the source must keep producing frames while the encoder keeps sending them.
Do not copy a stream key into a public script, screenshot, tutorial, or shared document. Anyone who obtains it may be able to send a feed to your event. You can create a new key or reset the existing one in YouTube Studio if you believe it has been exposed.
Check the input files and your FFmpeg build
Before choosing bitrate settings, inspect the files you intend to loop. Confirm their actual resolution, frame rate, audio sample rate, duration, colour format, and whether they contain video at all. A file labelled “4K” may have a different frame rate from another file in the same folder, and a mixed playlist can create timing or scaling problems.
A useful first check is:
ffprobe -hide_banner -show_streams -show_format input.mp4
This does not change the file. It reports the streams and container information that you need before building a command. Look for a video stream with dimensions of 3840 by 2160 if you are targeting UHD 4K, and check whether the source really contains 60 frames per second rather than 30 frames per second with a file name that suggests otherwise.
Check the FFmpeg version and the encoders available in that build as well:
ffmpeg -version
ffmpeg -encoders
The exact command you can use depends on the local build, the operating system, the input format, and the encoder hardware available to you. One installation may expose libx264; another may expose a hardware H.264 encoder such as h264_nvenc, h264_qsv, or h264_vaapi. The option names and supported rate-control modes can differ, so treat an example as a template rather than proof that it will run unchanged on your machine.
For a simple file loop, FFmpeg can read the same input repeatedly:
ffmpeg -stream_loop -1 -re -i input.mp4 \
-c:v libx264 -preset medium -pix_fmt yuv420p \
-r 60 -g 120 -keyint_min 120 -sc_threshold 0 \
-b:v 35M -minrate 35M -maxrate 35M -bufsize 70M \
-c:a aac -b:a 128k -ar 48000 \
-f flv "RTMPS_URL/STREAM_KEY"
This is a configurable example, not a tested command for a particular system. Replace the input, ingest URL, key, encoder, and any options that your build does not support. The -stream_loop -1 option repeats one input file. It does not by itself create a playlist of different files.
To rotate several files, you need a playback method that presents them as one continuous source, or a filter and concat workflow appropriate to those files. A concat workflow generally expects compatible streams or requires explicit normalisation. Do not assume that files with similar names have matching codecs, dimensions, frame rates, or audio layouts.
Choose the codec and bitrate for 2160p60
YouTube’s encoder guidance lists 2160p at 60 frames per second as a supported 4K target. For H.264, the guidance recommends a 35 Mbps video bitrate. For AV1 and H.265, it lists a 10–40 Mbps range. These are YouTube’s published encoder recommendations, not a guarantee that your upload connection, computer, hardware encoder, or source can sustain the result.
For the most broadly understood FFmpeg workflow, H.264 with AAC audio is a practical starting point. It is also the format used in the example above. If your local build and hardware support AV1 or H.265, you can investigate those options separately, but check the current YouTube documentation and your encoder’s actual output before switching.
The bitrate applies to the video stream. Audio uses additional bandwidth, and transport overhead also exists. YouTube recommends checking your upload speed, but the cited encoder guidance does not provide a universal fixed overhead margin. The safe practical approach is to measure sustained upload performance at the location where the stream will run and leave room for normal network variation.
The choice between software and hardware encoding is a capacity decision. Software H.264 may give you useful control over quality and rate control, but 2160p60 can place a substantial load on the processor. A hardware encoder may reduce processor use, but its available presets, quality, and rate-control options depend on the graphics or media hardware and driver.
The question is not simply whether FFmpeg can open the file. It is whether the whole chain can decode the source, resize or convert it if needed, encode 60 frames per second at the selected bitrate, and send the output for hours without falling behind. The guide on whether FFmpeg needs a GPU for 24/7 YouTube streaming is useful when you are comparing CPU and hardware encoding for a long-running channel.
If the source is already 3840 by 2160 at 60 fps, avoid unnecessary scaling. If it is smaller, scaling it up does not restore missing detail. If it is 30 fps, forcing -r 60 creates repeated or interpolated frames depending on the rest of the workflow; it does not turn the original material into genuine 60fps footage. Be clear about that distinction in your channel’s production plan.
Set frame rate, CBR and keyframes
A 4K60 stream needs consistent timing. YouTube’s guidance supports up to 60 frames per second and recommends a two-second keyframe interval, with no more than four seconds. At 60fps, a two-second interval corresponds to 120 frames, which is why the example uses -g 120 and -keyint_min 120.
The command also sets -sc_threshold 0 to reduce scene-change decisions that could produce keyframes at unexpected points. The exact behaviour still depends on the encoder. Some hardware encoders use different names or constraints, so check the help output for the selected encoder:
ffmpeg -h encoder=libx264
For a constant-bitrate style configuration, the example sets the target bitrate, minimum bitrate, and maximum bitrate to the same value, then sets a buffer size. This is a way to ask the encoder for a stable 35 Mbps video output. It is not a guarantee that every encoder will behave identically, and it is not a substitute for observing the actual output.
If your encoder does not accept one of these options, remove or translate it according to that encoder’s documentation. Hardware encoders often use their own rate-control flags. Running an invalid command repeatedly during a live event is avoidable; test the selected options with a short local output first.
The -re option tells FFmpeg to read the input at its natural playback speed rather than consuming the file as quickly as the machine can decode it. Without real-time pacing, a prerecorded source can run ahead of the live clock. That would produce a feed that is unsuitable for a normal live broadcast.
You should also decide how to handle transitions between files. A hard cut at the loop boundary may be acceptable for news slides or a music station, while a brief fade may suit meditation content. Do not add filters simply because they look sophisticated. Each filter can increase processing load and may change audio or video timing.
Prepare the YouTube Live event
Create or schedule the event in YouTube Studio before starting FFmpeg. Complete the title, description, visibility, audience setting, category, and other information that applies to your channel. Check the channel’s live-streaming eligibility as well. YouTube’s live-streaming guidance says the channel must be verified and must not have a live-streaming restriction in the preceding 90 days.
Choose the encoder workflow for the event and locate the stream URL and stream key. YouTube’s encoder streaming instructions describe entering these details into the encoder and starting the feed. The stream URL identifies where the feed goes; the key associates it with the event.
Treat the key as a credential. Keep it out of shell history where practical, out of public repositories, and out of screen recordings. If you need to share a command with someone, replace the key with a placeholder such as STREAM_KEY. Do not use a real key in a blog post or troubleshooting forum.
The event may show a preview before you make the broadcast public. Use that preview rather than assuming that a process with no error message is producing a correct stream. You can have a running FFmpeg process while YouTube receives the wrong dimensions, silent audio, an incorrect frame rate, or a feed that is too unstable to publish.
Set up ahead of the intended start time. A scheduled event gives you time to check the source playlist, confirm the thumbnail and metadata, and perform a short private or unlisted test. The test should use the same input type, resolution, encoder, and network path as the planned overnight stream.
Send the loop with the event’s ingest details
For an RTMP or RTMPS workflow, place the complete ingest destination at the end of the FFmpeg command. Keep the URL and key separate while preparing the command, then combine them only in the local environment where the feed will run. The placeholder form looks like this:
ffmpeg -stream_loop -1 -re -i "playlist-source.mp4" \
-c:v libx264 -preset medium -pix_fmt yuv420p \
-r 60 -g 120 -keyint_min 120 -sc_threshold 0 \
-b:v 35M -minrate 35M -maxrate 35M -bufsize 70M \
-c:a aac -b:a 128k -ar 48000 \
-f flv "YOUR_STREAM_URL/YOUR_STREAM_KEY"
Use the stream URL and key supplied for that event. Do not publish either value. If the command fails immediately, check the URL format, key, firewall, DNS resolution, and whether the chosen FFmpeg output format matches the ingest method.
The command above loops one file. To loop a playlist of several files, first decide how the source application will expose them to FFmpeg. Some applications have a repeat or playlist setting; others require a concat file or a prepared, normalised master file. Verify the current loop setting for the application you choose rather than assuming that a viewer-side YouTube playlist control affects it.
A prepared master file can be easier to reason about for a small channel. It gives you one input to inspect and repeat, but it may be large and less convenient to update. A playlist-aware playback workflow is more flexible, but it introduces another process that must remain open and correctly timed.
If you use HLS instead of RTMP or RTMPS, follow YouTube’s current ingestion requirements rather than adapting the command above. YouTube documents one-to-four-second transport segments, TS format, HTTPS POST or PUT, no byte ranges, and a rolling playlist with no more than five outstanding segments. Those are delivery requirements. They do not mean that HLS will repeat your source-video playlist.
Validate the preview and stream health
Start with a short test rather than committing an unobserved loop to the night. Watch the YouTube preview and check the rendered resolution, frame rate, audio, aspect ratio, and timing. Listen for silence at the beginning and at the loop boundary. Look for a frozen frame, black screen, missing overlays, or a visible gap between files.
The YouTube Live Control Room guidance recommends checking the preview and monitoring audio and video quality. Use the health indicators as evidence about what YouTube is receiving, not as a replacement for watching the actual output.
On the local machine, watch FFmpeg’s log. A growing number of duplicated or dropped frames can indicate a timing problem, a decoder issue, or a system that cannot keep up. If the process reports that it is running behind real time, reduce processing complexity or change the encoder after stopping the test. Do not quietly accept a feed that is several seconds behind at the start of a long broadcast.
Check the stream at more than one viewing point if possible. A channel operator may see a healthy preview while a mobile viewer on a different connection experiences buffering. This does not prove a fault in one particular component, but it helps separate an ingest problem from a viewer-side network problem.
Test the loop boundary specifically. Let the source reach the end of one item and start the next, or reach the end of the whole prepared file and repeat. Confirm that video does not flash black and that audio does not remain silent. If the source files use different dimensions or audio layouts, normalise them before attempting a full-length broadcast.
Keep a local recording when the programme matters. YouTube says streams under 12 hours can be automatically archived, while a stream longer than 12 hours may not be captured at all. It also recommends a local archive backup. A continuous channel therefore needs its own plan for preserving source files and, where appropriate, recording the outgoing programme.
For a practical recovery plan, see how to back up a 24/7 YouTube channel’s files, keys and metadata. If the stream disconnects overnight, the recovery steps should be written down before the first unattended run. Include where the source files live, how the event is restarted, and how a compromised key is replaced.
Account for latency, bandwidth and local capacity
YouTube says 4K streams use normal latency rather than the low-latency option. That affects how quickly viewers see the feed and how quickly you can observe a problem from the public playback page. It is not a reason to lower the video quality, but it is a reason to set realistic expectations for live interaction.
At 35 Mbps video bitrate, your connection must sustain a substantial outbound flow for the entire stream. A speed test taken once does not prove that the connection will remain stable overnight. Test at the intended location and time, watch for upload contention from other devices, and avoid placing a large backup or software update on the same connection while live.
The local computer must decode the source, apply any filters, encode 2160p60, and transmit the result. Monitor processor load, graphics or media-engine load, memory use, temperature, disk activity, and network stability during the test. A machine that runs a short clip successfully may still fail when a filter, file transition, or background process appears later.
If you do not want to leave a computer running and monitored, a managed cloud workflow can remove the local playback and recovery burden. StreamNeo is useful here because you upload the file once, provide the YouTube stream key, and the 24/7 broadcast continues with automatic monitoring and restart while your computer is switched off.
That convenience does not remove the need to check your media rights, event details, output quality, and YouTube’s current requirements. It also does not turn a viewer playlist into a source playlist automatically. You still need to prepare the files and confirm how the chosen workflow repeats them.
When comparing local FFmpeg with a continuous-streaming service, use concrete questions: does it repeat the files in the required order, accept 4K60 output, provide monitoring, recover after a dropped connection, preserve a local archive, and fit your upload or cloud-ingest limits. The comparison guide on how to compare 24/7 streaming services without getting fooled is useful when a low headline price hides manual work or limits that matter to an unattended channel.
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 YouTube loop my playlist as a live broadcast?
No. YouTube’s playlist repeat control repeats playback for a viewer, but it is not documented as a playlist-to-live encoder. You need a playback workflow that repeats the prerecorded material and an encoder that sends the resulting feed to your live event.
What bitrate should I use for 4K60 H.264?
YouTube’s encoder guidance recommends 35 Mbps for 2160p60 H.264. Treat that as a starting recommendation, then confirm that your encoder and sustained upload connection can produce and carry it without dropped frames or instability.
Can I use a 30fps source for a 4K60 stream?
You can configure the output for 60fps, but that does not create new source detail or genuine 60fps motion. Repeated or converted frames may be acceptable for some content, while a native 60fps source is preferable when smooth motion is important.
How long can the stream run before archiving becomes risky?
YouTube says streams under 12 hours can be automatically archived, while a stream longer than 12 hours may not be captured at all. For a longer continuous channel, keep your own source and recording plan rather than relying only on YouTube’s archive.