To loop an MP4 from Ubuntu to YouTube Live, run FFmpeg so it reads the file in real time, repeats it and sends a supported live output to the ingest address shown in YouTube Studio. The command must be adapted and tested for your particular file, server and upload connection; there is no single safe recipe for every MP4.
The workflow is: enable live streaming, inspect the file, choose whether to copy or re-encode its streams, protect the stream key, then test the preview and monitor the process. A server can keep the encoder running without a desktop, but it does not remove the need to check stream health, recovery behaviour and archive limits.
How Ubuntu, FFmpeg and YouTube Live fit together
Ubuntu hosts the process; FFmpeg reads and packages the video and audio; YouTube receives the encoded stream at an ingest URL. The MP4 is an input file, not itself a live broadcast. FFmpeg must send its contents at playback speed rather than as quickly as the host can read the disk.
For a repeating file, FFmpeg's input options matter. -re asks it to read at the file's native rate, while -stream_loop -1 requests an infinite loop. Both are input-side settings and belong before the input filename. The FFmpeg documentation for input options describes -stream_loop and its -1 setting for infinite looping.
After the input, FFmpeg either copies compatible encoded streams or decodes and encodes them into output streams accepted by YouTube. It then muxes those streams into a live output format and publishes them continuously. Copying can save CPU and avoid another generation of quality loss, but it is not a universal shortcut: the existing codecs, timestamps and muxing compatibility have to work for this output. Re-encoding gives you control over format and rate, at the cost of CPU use and another encoding step.
A useful way to think about the setup is as separate checkpoints: can FFmpeg read the file; can it produce a suitable output; can the server sustain that output; and does YouTube show a healthy preview? If a stream fails, checking those stages in order is usually more useful than changing several flags at once. If you are weighing control against the work of maintaining an encoder, this comparison of FFmpeg and a cloud service outlines the operational trade-offs.
Enable live streaming and create a stream in YouTube Studio
Sign in to the channel that will broadcast and open YouTube Studio's Live Control Room. Enable live streaming if it is not already enabled, then create or select the stream you intend to use. YouTube says first-time activation may take up to 24 hours, so do this before scheduling a test that depends on the channel being ready. Check the current YouTube Help instructions for enabling live streaming.
In the stream's settings, locate the server URL and stream key. FFmpeg needs both: the server address identifies YouTube's ingest endpoint, and the key associates the incoming broadcast with the selected stream. Use the values shown in Studio rather than copying an endpoint from an old tutorial. YouTube's live encoder settings guidance also covers its current ingest expectations and testing advice.
Keep the Live Control Room open during the first setup. It is where you can confirm that YouTube has received a preview, inspect stream health and check whether the intended stream is selected. Creating a stream does not mean that the file is already being broadcast, and a successful FFmpeg process alone does not confirm that the preview is visible to viewers.
Prepare and inspect the MP4 input
Put the file in a stable location on the Ubuntu host and confirm its exact path and spelling. A path containing spaces must be quoted in the shell command. Check that the account running FFmpeg can read the file and that it is not a temporary upload that will disappear after a reboot or deployment.
Before choosing encoding flags, inspect the media. ffprobe is distributed with FFmpeg and can report the video and audio streams, codecs, dimensions, frame rate and duration. For example:
ffprobe -hide_banner /path/to/video.mp4
Read the output rather than assuming that every .mp4 contains H.264 video and AAC audio. An MP4 is a container; its streams and properties can vary. Note whether audio exists at all, whether it is stereo or mono, and whether the picture's frame rate is constant or variable. These details affect whether copy is plausible and how you should set an encoder.
If FFmpeg cannot open the file, resolve that before adding a live destination. Check the path, permissions and whether the file is complete. If the file plays locally but has an unusual codec or variable frame rate, test a short transcode first. A loop magnifies a defect that appears at the end or beginning: watch the transition between the last and first frames, and listen for a gap or abrupt audio change.
Also confirm that you have the rights and permissions needed to broadcast both picture and sound. A technical setup cannot establish those rights for a particular file. For a worship or devotional programme, the practical concerns around using a prepared recording are also discussed in this guide to streaming pre-recorded worship services.
Configure the loop and real-time output
Start with a test that runs for a short period, not an unobserved overnight session. The following is an example command shape using re-encoding. It is not a universal recipe, and the values are illustrative rather than requirements for your MP4:
ffmpeg -re -stream_loop -1 -i /path/to/video.mp4 \\
-c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Do not run this with the placeholders unchanged, and do not paste a real key into a public document. The video bitrate, GOP values, audio settings, encoder and destination all need a decision based on the inspected file, YouTube's current guidance and the server's capacity. In the example, a 60-frame GOP corresponds to two seconds only when the output is 30 frames per second. At a different frame rate, choose the GOP accordingly rather than treating 60 as universal.
The -re and -stream_loop -1 options appear before -i because they control how FFmpeg reads the input. The codec and bitrate options that follow apply to output. If the file has no audio stream, an audio encoder setting cannot create meaningful programme audio; decide whether silent video is appropriate or whether to provide an audio source. If audio exists in a format YouTube accepts and the container supports it, stream copy may be worth testing, but verify the resulting preview and stream health.
Avoid adding more options until you can explain what each one is meant to solve. A complex command makes it harder to isolate a failure. Save a working, key-free template, document which settings you changed for this file, and keep the final credential outside shared notes and version-controlled scripts.
Add the ingest URL and protect the key
Copy the server URL and key from the exact YouTube Studio stream you selected. YouTube's RTMPS guidance recommends the encrypted RTMPS connection for data sent to its servers. Use the address supplied for that stream rather than assuming that a fixed endpoint, protocol or URL path applies to every account and workflow.
A stream key functions as a credential. Anyone who obtains it may be able to send a broadcast to the associated stream. Do not include it in a public repository, a screenshot, a support post, or a command example shared with others. Shell commands can also remain in shell history or appear in process listings, depending on how they are launched, so think about who can access the account and host before choosing how to supply the secret.
For a self-managed setup, keep credentials in a file or environment available only to the account that needs them, restrict file permissions, and avoid printing them in logs. If a key is accidentally exposed, rotate it in YouTube Studio and update the local configuration. The exact secure mechanism depends on how you administer the host; the important point is to separate the credential from reusable, shareable command text.
This is often where a small server setup becomes operationally tedious: a local machine must stay powered, the key must remain private, and the process needs attention when it stops. StreamNeo removes the need to leave your own computer running by turning an uploaded video into a YouTube broadcast, while still leaving you responsible for choosing material you may broadcast and checking the channel.
Match encoding settings to the file and upload
YouTube's current encoder guidance lists H.264, H.265/HEVC and AV1 video for RTMP/RTMPS, and AAC or MP3 audio. It specifies constant bitrate encoding, recommends a two-second keyframe interval that should not exceed four seconds, and recommends stereo audio at 44.1 kHz and 128 Kbps. These are YouTube's ingest recommendations, not proof that a particular Ubuntu host, file or network can sustain a broadcast. Check the current encoder settings and bitrate table before settling on output settings.
For context, YouTube lists H.264 at 1080p30 with a 5 Mbps minimum and 14 Mbps recommended video bitrate, and 720p30 with a 3 Mbps minimum and 8 Mbps recommended. Those figures describe YouTube's guidance for those specific output formats. They are not universal encoding requirements, and a higher bitrate is not automatically better if the server's upload cannot sustain it. YouTube recommends a speed test so you can assess upload bitrate; leave enough headroom for variation rather than selecting a rate that only works at the best moment of a test.
| Decision | What to check | Practical implication |
|---|---|---|
| Copy or re-encode | Existing video/audio codecs and output compatibility | Copy saves CPU and avoids re-encoding loss; transcode when the source or container does not suit the output. |
| Resolution and frame rate | Source dimensions and frame rate, plus the quality you can upload steadily | Avoid requesting a larger output without a reason; converting can consume CPU and affect picture quality. |
| Video rate | YouTube's current recommendation for the selected format and measured upload capacity | Choose a stable rate the host can sustain, not simply the largest listed figure. |
| Keyframe interval | Output frame rate and YouTube's current interval recommendation | Translate seconds into frames for the chosen output rate; do not copy a GOP number blindly. |
| Audio | Whether the source has audio, its channel layout and codec | Set audio output deliberately; do not assume an MP4 contains a usable audio track. |
If you transcode, watch CPU use during the test. A host that cannot encode in real time will fall behind or drop frames even if its network is adequate. If you stream-copy, check for timing and container problems at the preview and at the loop boundary. For issues that present as clipped sound rather than a failed connection, this guide to preventing clipping on a continuous stream offers useful checks.
Test the preview and diagnose common failures
Start FFmpeg and allow time for YouTube to receive and process the incoming feed. Confirm that the correct preview appears in Live Control Room, then watch the moving picture and listen to the audio. Check that the opening is not frozen, the file's loop transition is acceptable, and the audio is not missing, distorted or unexpectedly quiet. Follow the Studio stream-health messages rather than relying only on the terminal's lack of errors.
If there is no preview, check the copied server URL and key, the selected stream in Studio, and whether first-time activation has completed. An authentication or connection error can be a credential or destination issue; avoid posting full command lines or logs publicly if they contain the key. If FFmpeg exits immediately, inspect the first error in its output and verify the file path, permissions, and encoder availability.
If the picture stutters or health warnings appear, consider both sides of the link: CPU pressure if encoding, and sustained upload capacity. Lowering output quality may help only if the encoding load or bitrate is the cause; it will not fix a bad key or an unreadable file. A VPS can have a fast advertised connection while still experiencing interruptions, so observe the actual stream. See the practical sequence for troubleshooting buffering from a VPS.
A first test should include enough playback to reach the file's end and return to the beginning. That catches failures a short preview cannot show, including a timestamp discontinuity, a gap, or a sudden audio change. Make one adjustment at a time and repeat the same check so you can tell whether the change helped.
Plan recovery and archive boundaries
An FFmpeg process is not a complete operations plan. The Ubuntu host needs to stay online, the file must remain accessible, and the connection needs sufficient sustained upload capacity. If the process exits or the host reboots, YouTube does not itself restart your local encoder. A process manager such as systemd can start the job after reboot and restart it after an exit, but configure and test that behaviour rather than assuming it works. Keep credentials protected in the service configuration, restrict access, and check logs without exposing secrets.
Monitor the things that explain a failure: whether FFmpeg is still running, CPU load when transcoding, available disk space, network interruptions, and YouTube's stream-health messages. Restarting a process can restore an interrupted broadcast, but it cannot repair a corrupt file or an unstable connection. If you need a step-by-step recovery model, see how to recover a YouTube stream after FFmpeg exits; adapt its EC2-specific details to your Ubuntu host rather than copying them blindly.
Decide separately whether a continuous archive matters. YouTube states that live streams under 12 hours are automatically archived. Do not rely on a complete archive for a longer continuous session; if a full recording matters, plan shorter sessions within YouTube's documented duration and verify current behaviour in Studio. Restarting a stream has operational consequences, including a new session to monitor, so weigh that against the archive requirement.
Self-hosting gives you direct control over the file, command and process, but you take responsibility for host availability, upgrades, credential handling and recovery. A managed cloud workflow can remove the need to maintain an Ubuntu process, while offering less hands-on control over the encoder. Choose based on the work you are willing to own, the predictability of your upload, and whether archive boundaries matter for the 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 I use stream copy instead of re-encoding?
Sometimes. It avoids decoding and encoding, which can reduce CPU use and avoid quality loss from another encode, but the source codecs and output muxing need to be compatible. Inspect the MP4, test the stream and re-encode if YouTube does not receive a suitable output.
Why put -re and -stream_loop before the input?
They are input options: -re makes FFmpeg read at the file's native rate, and -stream_loop -1 requests an infinite repeat. Place them before -i so they apply to the file input. The rest of the command still needs to suit your file and output.
Does a running FFmpeg command mean my channel is live?
No. It means the process is running; check the Live Control Room for the correct preview and stream health. Test the picture, sound and loop boundary before relying on it, then arrange monitoring and recovery for the host.
Will YouTube archive an all-day stream?
YouTube says streams under 12 hours are automatically archived, but you should not assume a complete archive for a longer continuous session. If the recording matters, check YouTube's current guidance and Studio behaviour and plan sessions accordingly.