To run a prerecorded video as a 4K 60fps YouTube Live loop from Ubuntu Server, configure an encoder to send the video and audio repeatedly to your YouTube stream URL and key over RTMPS. Set the output to 3840×2160 at 60 fps using YouTube’s codec guidance, then verify the format and stream health in Live Control Room before leaving it unattended.
YouTube documents the ingest requirements, not a tested Ubuntu command or production-ready service file. The examples below are implementation starting points: check the installed encoder, source file, audio handling and recovery behaviour on your own system before relying on them overnight.
What this Ubuntu Server workflow does
A live loop is a continuous transmission to a YouTube Live event. Your Ubuntu machine reads a local media file, repeats it when it reaches the end, encodes or passes through its audio and video, and sends the result to YouTube. The YouTube event is the destination; the loop and its restart policy belong to your local setup.
This is different from uploading a video and publishing it as a normal on-demand item. A live event receives a stream from an encoder, and the stream key identifies where that encoder sends it. YouTube says streams under 12 hours are automatically archived; that does not mean a long-running transmission is guaranteed to be archived or to remain healthy. Plan the event and any desired recordings with that limitation in mind.
The target picture format is 3840×2160 at 60 frames per second. Choosing those values in an encoder is not proof that YouTube receives them: YouTube can detect resolution and frame rate automatically, and you should check the received format and stream health in Live Control Room. If you are comparing a local FFmpeg loop with other ways to keep a channel on air, the Ubuntu 24.04 always-on FFmpeg guide may help with the broader workflow, but it does not validate the 4K settings or commands in this article.
There are two separate capacity questions. Can the Ubuntu machine produce the selected output reliably, and can its network upload that output steadily? YouTube’s recommended bitrate describes what to send, not what your ISP or server connection can sustain. A setting cannot create upload capacity, and a brief successful test cannot establish overnight stability.
Prepare the YouTube Live event and credentials
Create or schedule the live event in YouTube Studio and note the event’s ingest details. In the encoder, the stream URL and stream key are separate fields: the URL gives the destination, while the key associates the incoming feed with the channel or event. YouTube describes the key as a password and address for the stream. Treat it as a credential, not as ordinary configuration text.
Use the current instructions in YouTube Help for setting up a live stream and check the event’s Live Control Room for the actual URL and key. The RTMPS option is appropriate for ordinary live ingestion; YouTube’s RTMPS ingestion guide describes its secure ingest endpoint and port 443. Use the endpoint YouTube provides rather than substituting a URL found in an old script or forum post.
Keep the key out of shared scripts, public repositories, screenshots and logs that other users can read. Avoid pasting it into a shell command that remains in shell history. If a key is exposed, reset it in YouTube Studio and update the encoder configuration. A working key is not proof that the correct event is selected: confirm in Live Control Room that the incoming feed appears on the intended event before starting a long run.
YouTube can detect the incoming resolution and frame rate automatically, which is its default recommendation on the encoder settings page. A custom stream key can be used when you need manually specified settings. Whichever route you choose, inspect the format YouTube reports. If it reports a lower resolution or frame rate than expected, troubleshoot the source and encoder output rather than assuming that selecting 2160p60 locally settled the matter.
For a walkthrough focused on moving credentials between tools, see the guide to transferring a YouTube stream key safely. The same principle applies on Ubuntu: use only the credential where needed and restrict who can read any file that contains it.
Choose a codec and 2160p60 ingest settings
YouTube lists H.264, H.265/HEVC and AV1 as supported video codecs. Its current encoder guidance recommends 35 Mbps for H.264 at 4K/2160p and 60 fps; for AV1 and H.265 at that mode it lists an ingestion bitrate range of 10–40 Mbps. These are YouTube recommendations, not measurements of the capacity of your Ubuntu host or connection. Consult YouTube’s encoder settings and bitrate guidance for current requirements before configuring an event.
YouTube also recommends constant bitrate (CBR) encoding and a two-second keyframe interval, which should not exceed four seconds. Its guidance supports frame rates up to 60 fps. These are destination-side recommendations; whether a particular FFmpeg build and encoder can apply them as intended depends on the installed version, codec and hardware. Check the encoder’s own output and the received status in Live Control Room.
| Choice | YouTube guidance for 2160p60 | What to check locally |
|---|---|---|
| H.264 | Recommended bitrate: 35 Mbps | Whether the installed encoder can sustain the chosen output and CBR setting |
| H.265/HEVC | Ingestion range: 10–40 Mbps | Whether the encoder supports it and whether the source and destination workflow suit it |
| AV1 | Ingestion range: 10–40 Mbps | Whether the installed software or hardware can encode it at the required rate |
| RTMPS | Recommended for ordinary live ingestion | That the endpoint is the one shown for the event and the connection reaches it |
| HLS | An alternate ingest path for some HDR or codec needs | Whether its codec/HDR support is needed and whether added latency is acceptable |
Do not select AV1 or H.265 solely because their listed range appears lower than the H.264 recommendation. Real-time encoding load varies with the system and settings, and the research behind this guide does not establish which codec any Ubuntu Server can encode in real time. Test the installed encoder with the intended source and watch for dropped frames or machine load. If you need only a conventional SDR loop and H.264 works reliably, a more unusual codec is not automatically an improvement.
YouTube documents HLS as an alternative for HDR or codecs that RTMP does not support. HLS sends segments rather than one continuous RTMP-style stream, so its guidance notes higher latency. For a typical low-latency live transmission, YouTube recommends RTMPS. Choose HLS only when its supported format is relevant to your use case and the latency trade-off is acceptable; confirm the currently supported settings on YouTube’s official pages.
Inspect the source and installed encoder
Before writing a loop command, find out what the media file actually contains. Check its duration, video dimensions, frame rate, pixel format, codec, audio codec, sample rate and channel layout. A file labelled “4K” might not be 60 fps; audio may be absent, or its layout may not match the encoder settings you intend to use. The source’s properties determine whether to preserve, convert or add streams, and each conversion changes the work required from the server.
Inspect the installed FFmpeg build rather than assuming that an example from another Ubuntu machine applies. Check the FFmpeg version, available encoders and the options for the encoder you intend to use. Hardware encoding may depend on drivers and device access; software encoding has different CPU demands. If the encoder name in a sample is not listed locally, the command will fail. If the encoder exists but cannot keep pace, it may produce a poor or interrupted feed.
A simple discovery pass might use ffmpeg -version, ffmpeg -encoders, and a media probe such as ffprobe -hide_banner -i input.mp4. These are inspection examples, not a complete validation procedure or a promise that every build includes the same components. Read the output, identify the intended video and audio streams, and check the encoder documentation for your installed version. Do not paste a stream key into a diagnostic command or share output that exposes credentials.
The output should match the destination mode in both resolution and frame rate. If you need to convert a lower-resolution or lower-frame-rate source, scaling and frame-rate conversion do not restore detail or motion that was never present in the original. Upscaling a 1080p file to 2160p may satisfy a frame-size setting but does not make its image native 4K. For an archive of source-management approaches, the Raspberry Pi playlist streaming guide offers a different device context; its assumptions should not be carried over to a 4K Ubuntu encoder.
Also check available disk space, file readability after a reboot, and the network path from the host to YouTube. A local file that is on a removable mount or encrypted volume may not be available when a service starts. Keep the source somewhere the service account can read, and verify that permissions do not inadvertently expose the stream key or media to other users.
Build and validate a looping implementation
The loop has two jobs: repeat the media and send a compatible live output. FFmpeg can be used to implement both, but the reviewed YouTube documentation does not supply or validate a particular Ubuntu command. Treat any command as an implementation example to adapt after checking your FFmpeg build, source streams, desired codec, audio, keyframe interval, bitrate and signal handling.
A common FFmpeg pattern for looping a file is to use an input loop option, then specify output encoding and an RTMPS destination. The exact option placement and combination depends on the input and FFmpeg version. A placeholder outline, not a runnable or production-ready command, is:
ffmpeg [input options including a loop, if supported] -i /path/to/input.mp4 \\
[map the intended video and audio streams] \\
[set output size, frame rate, codec, CBR target and keyframe interval] \\
-f flv [RTMPS URL with the protected stream key]
Do not copy this outline into a service file. It deliberately omits actual codec-specific flags and credentials because those need to be selected for the installed encoder and protected appropriately. In particular, a flag accepted by one encoder may not mean the same thing for another, and the source may need audio resampling or no audio mapping at all. Consult the local FFmpeg documentation and test with a non-public or scheduled event before relying on it.
Validate in stages. First, run a local encoding test without sending to YouTube and observe whether the encoder can maintain the intended frame rate. Then send a brief test to the intended event and check Live Control Room for the received resolution, frame rate, bitrate behaviour, audio and stream health. YouTube’s page may show that it is receiving a feed even if the image or sound is wrong, so watch and listen to the actual preview.
Check the beginning, the point where the file should wrap, and a later point in playback. A loop that exits when the file ends is not a loop; an input option that repeats but breaks on a signal may not recover cleanly. Listen for silence, clipping or an abrupt transition at the boundary. If video and audio drift, inspect timestamp and stream mapping rather than adding arbitrary delays. Only after the short test behaves as intended should you proceed to longer monitoring.
For a local FFmpeg workflow aimed at an always-on channel, the 24/7 Ubuntu stream guide is useful background, but treat its commands as separate examples that also require local verification. The test result belongs to your version, file and hardware; it is not a general guarantee for another host.
Run as a monitored service
A service manager can start the encoder after reboot, keep it in the background and record process output. That makes recovery easier to organise, but it does not make the stream itself reliable by default. The service must know where the media is mounted, have permission to read it, receive the credential safely, and handle a stopped encoder without creating a rapid restart cycle. It also needs logs you can inspect without exposing the stream key.
A systemd unit is one possible implementation, not a YouTube-certified configuration. Before writing one, decide which account runs the process, how credentials are supplied with appropriate file permissions, where logs go, and how restart behaviour should work. Confirm that the chosen FFmpeg command handles termination signals so the service can stop cleanly. A service that restarts a failing command repeatedly can hide an underlying network or configuration problem while filling logs.
Do not place a real stream key in a world-readable unit, a shared shell script or a repository. Restrict access to any environment or configuration file that contains it, and check what the service manager records in its status and logs. If your operating model requires another person to maintain the channel, give that person access through a deliberate credential-management process rather than sending a key in a public ticket or chat.
Monitoring should answer practical questions: is the encoder process running, is it producing output, can the machine read the media, and does Live Control Room show an incoming healthy feed? A running process alone cannot answer the last question. If you want to compare a local server with a managed workflow where the computer need not remain switched on, first establish the operational requirements and costs; the guide to keeping an Indian internet radio stream live during power cuts discusses a related continuity problem, though its radio assumptions differ from this 4K setup.
Test recovery before unattended use
Test the failure modes you expect before leaving the channel running. Stop the encoder deliberately and see whether your chosen service policy restarts it as intended. Reboot the host and check that the service starts only after the media is available. Test what happens if the network drops briefly, the stream key is reset, or the file becomes inaccessible. These are controlled checks, not reasons to expose the key or interrupt a public event without planning.
After each test, look at both sides of the connection: service logs on Ubuntu and event health in Live Control Room. Confirm that a restarted encoder reconnects to the intended event and that YouTube again reports the expected received format. If the host reports a running process but the control room shows no feed, the failure is not solved. If the feed returns at a different resolution, investigate the encoder’s actual output.
A long test is useful for discovering issues that a short preview will not show, such as storage exhaustion, unexpected thermal or CPU limits, service log growth or a loop boundary problem. It still cannot guarantee that a connection will remain available indefinitely. Keep an alert or a routine check appropriate to the importance of the channel, and know who will respond if the feed stops. For devotional, study or local-information channels, a clear recovery procedure is often more useful than assuming a single unattended command will run forever.
Once the workflow has been validated, document the Ubuntu release, FFmpeg build, encoder choice, source properties, service configuration location, log location and credential reset procedure. Avoid recording the key itself in the handover document. This record makes a future update easier to assess: after a package, driver or source-file change, repeat the relevant tests rather than assuming earlier results still apply.
If this server-side upkeep is the specific pain you are trying to remove, StreamNeo turns an uploaded video into a YouTube live stream that can run with your own computer switched off; it is YouTube-only, so check that this matches your workflow. It does not change the need to prepare the file and channel, or to confirm that the destination is receiving the intended stream.
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?
Use an encoder on a computer or server to repeat the file and send its audio and video to the event’s stream URL and key. On Ubuntu, FFmpeg is one possible implementation, but the exact command depends on the installed build and the file’s streams. Verify that YouTube receives a healthy feed and that playback continues past the file’s end.
How do I stream prerecorded video 24/7?
Keep an encoder sending the file repeatedly to a YouTube Live event, and arrange for your host or chosen service to monitor and recover the process. Test reboot, network interruption and loop behaviour before leaving it unattended. No command or service policy can guarantee continuous connectivity.
How do I stream 4K 60fps from Ubuntu Server?
Configure the output for 3840×2160 at 60 fps and apply YouTube’s current codec-specific bitrate and keyframe guidance. Confirm the source, installed encoder and available system capacity first, then check the format actually received in Live Control Room. The settings do not prove that your network can sustain the upload.
Should I use RTMPS or HLS?
YouTube recommends RTMPS for ordinary live ingestion. Its HLS option may suit some HDR or codec requirements, but segmented delivery can add latency. Check YouTube’s current guidance and choose HLS only when its format support matters more than that trade-off.