FFmpeg can send a prerecorded video to YouTube Live continuously by reading the file at its normal speed, looping it, encoding it, and publishing the result to YouTube’s ingest address. You need a YouTube stream URL, a private stream key, a computer or server that can keep running, and a stable upload connection.
The command below is a starting point, not a guarantee that every FFmpeg build will accept the same options. Test it with an unlisted or private broadcast first, then adjust the codec, bitrate, frame rate and supervision around the equipment you actually have.
What FFmpeg does in a 24/7 setup
FFmpeg is a command-line media tool. In this workflow it performs several jobs in sequence: it opens your video file, controls the reading speed, repeats the input when it ends, converts the video and audio into a YouTube-compatible format, and sends the resulting stream over RTMP or RTMPS.
A file played in a normal media player stops when it reaches the end. A 24/7 FFmpeg process needs different behaviour. The input must be paced so that FFmpeg does not read the file as quickly as the computer can process it, and it must be opened again when playback reaches the end. The -re option is commonly used to read a file at its native rate. The -stream_loop -1 option asks FFmpeg to repeat the input indefinitely.
That solves the media loop, but it does not solve every operational problem. The command does not automatically repair a failed internet connection, restart after a power cut, replace a damaged source file, rotate recordings, or supervise the host. Those are separate decisions.
YouTube receives the encoded feed and creates viewer formats from it. Your computer still has to encode the selected output and upload it continuously. A devotional channel with a mostly static image may use less processing than a detailed local-news loop, but both need a process that remains available through the night.
For a broader view of the practical checks around a long-running broadcast, use the 24/7 stream pre-flight checks before making the feed public.
Prepare YouTube Live credentials securely
Open YouTube Studio and use the Live Control Room to create or select a stream. YouTube provides an ingest URL and a stream key for the encoder. The URL identifies where the feed should go; the key authorises the connection for that stream. The labels and available controls can change, so confirm the current process in YouTube’s live streaming help.
Treat the stream key like a password. Do not place it in a public tutorial, screenshot, shared document, public Git repository or support ticket. It can also appear in shell history, process listings or diagnostic output, depending on how you start FFmpeg. If the key is exposed, rotate or reset it in YouTube Studio rather than continuing to use it.
A simple command-line example places the key in the destination URL, but that is not the only way to handle it. On a shared machine, consider using a protected environment variable or a private configuration file with restricted permissions. Check the actual command and system logs afterwards to make sure the key has not been recorded in plain text.
Before starting a continuous broadcast, check whether live streaming has been enabled on the account and whether YouTube has imposed any waiting period or account requirement. Use a private or unlisted event for the first test where that suits your channel. The objective is to confirm the complete path from file to preview, not merely to see whether FFmpeg starts without an error.
YouTube may offer automatic start and automatic stop controls. These can be useful, but they do not remove the need to inspect the preview and stream health. Decide whether the event should begin when the encoder connects or only after you manually select the relevant control in Live Control Room.
Choose a media input and loop behaviour
Start with a file that you own or are permitted to broadcast. Check its duration, aspect ratio, frame rate, audio tracks and overall condition. A file that plays correctly once is not automatically a good overnight source: inspect its final seconds, confirm that it has a usable audio track, and watch at least one complete loop for an abrupt cut, frozen frame or missing sound.
For a single prerecorded file, the input portion of a command may look like this:
-re -stream_loop -1 -i input.mp4
Here, input.mp4 is the source file. -re applies real-time pacing to the file input. -stream_loop -1 requests an unlimited number of repeats. The exact option support depends on the FFmpeg version and build, so check the documentation installed with your version if the command is rejected. FFmpeg’s official documentation explains how input and output options are arranged and how looping options apply to inputs.
A loop is not the same as a playlist. If you need several files, you may need FFmpeg’s concat methods or a separate playlist process. Those approaches have their own requirements, including matching streams, handling different durations and deciding what happens when one file is corrupt. Do not assume that adding several unrelated files to one command will produce a clean transition.
The source’s frame rate matters later when you choose the keyframe interval. A two-second keyframe interval means 60 frames at 30 frames per second and 120 frames at 60 frames per second. It is a duration, not a fixed frame count.
If the source is already encoded in a format suitable for the destination, you may be tempted to copy the streams rather than encode them again. That can reduce processing, but it removes your control over output resolution, bitrate, frame rate and codec compatibility. For a first setup, an explicit transcode is easier to inspect. If you later test stream copying, verify the result with the actual YouTube preview and stream health rather than assuming that the source is suitable.
An always-on playlist also has editorial considerations. A bhajan loop may need a clean transition and consistent loudness. A study stream may need a continuous black screen during a break rather than a failed process. A local-news loop may need its dated material replaced before it becomes stale. FFmpeg can repeat a file, but it cannot decide whether the content remains appropriate for your viewers.
Set pacing, video, audio and output
YouTube’s current encoder guidance should be the reference for the selected codec, resolution and frame rate. Its settings page covers H.264, HEVC and AV1 ingest, frame rates up to 60 fps, constant bitrate operation and a recommended keyframe interval of two seconds, with no more than four seconds. Check the current YouTube live encoder settings before fixing a production command.
A representative H.264 starting pattern is:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -b:v 5000k -maxrate 5000k -bufsize 10000k \
-g 60 -c:a aac -b:a 128k \
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
This is an illustrative pattern, not a universal command. It assumes that the FFmpeg build includes the libx264 encoder, AAC support and the required FLV and RTMP or RTMPS components. Some builds may use different available encoders or reject an option. Replace the placeholder destination with the value supplied by YouTube, and confirm the correct URL format in your Live Control Room.
The 5000k video rate in this example is only an example, not a general YouTube recommendation. YouTube’s table gives different recommendations for different codecs, resolutions and frame rates. For example, its listed H.264 recommendations include 14 Mbps for 1080p30, 17 Mbps for 1080p60, and 8 Mbps for both 720p30 and 720p60. These values are published guidance for those combinations, not measurements of your connection or a promise of a particular picture quality.
At 1080p30, YouTube lists 10 Mbps for AV1 and HEVC, compared with 14 Mbps for H.264. Choose the codec your FFmpeg build can encode reliably and your host can process continuously. A newer codec is not automatically the right choice if the encoder is unavailable, unstable or too demanding for the machine.
The output setting should match the source and the upload connection. If the connection cannot sustain the recommended rate with headroom, reducing resolution or frame rate is usually more sensible than keeping a larger picture that repeatedly drops packets. YouTube recommends leaving 20% bandwidth headroom. If you are sending a primary and backup feed, account for both bitrates.
The audio example uses AAC at 128 kbps. YouTube’s guidance also covers MP3 and recommends a 44.1 kHz sample rate for stereo audio. If your source has unusually loud material, check the result on headphones and a phone before leaving it unattended. A technically connected stream can still be unusable if the audio is silent, clipped or badly out of balance.
The -g 60 value means a 60-frame GOP. It represents two seconds only when the output is 30 fps. If you output 60 fps, use a value that produces the intended two-second interval, subject to the capabilities of your build and the rest of your encoder settings. Do not copy a frame count without checking the frame rate.
For HDR, use YouTube’s separate current requirements rather than applying this SDR example. The same applies to unusual frame sizes, variable frame-rate material and sources with multiple audio tracks. The more the source differs from a conventional SDR file, the more important it is to test the actual output before publishing.
Send the feed to YouTube over RTMP
The final part of the workflow is the output destination. FFmpeg packages the encoded streams as FLV and publishes them through the address provided by YouTube. RTMPS is YouTube’s recommended secure extension to RTMP where supported by the software and destination shown in your Live Control Room.
Keep the destination in one quoted argument when it contains special characters. The command’s final output options, including -f flv, tell FFmpeg how to package the feed. Input options belong before the input file, while output options generally belong with the output they control. Small changes in option placement can change what a setting applies to.
When FFmpeg starts successfully, you should see it report frames, time, speed and bitrate. A process that keeps printing progress is not proof that YouTube is receiving a healthy feed. Open the Live Control Room and wait for the preview. Check the picture, motion, audio and reported stream health before choosing “Go live” if the event is not configured to start automatically.
If YouTube rejects the connection, work through the cause rather than repeatedly exposing the key. Confirm the URL and key, inspect whether the key was reset, check that your build supports the selected encoder, and read the first meaningful error from FFmpeg. A destination copied with an extra space or a source that has no usable audio can create a different problem from a blocked network connection.
Your viewers may see a delay between the encoder and the watch page. That delay is normal for live delivery and can vary with the selected YouTube latency settings. Judge the output on the channel or watch page as well as in the preview, especially if your stream includes speech, music or timed captions.
Run FFmpeg on a suitable computer or server
The host must remain powered on, connected and able to encode for as long as the broadcast is intended to run. A laptop that sleeps when its lid closes is not a suitable unattended host until its power and sleep settings have been changed and tested. A desktop that restarts after updates may also interrupt the feed unless you have planned for that behaviour.
Measure the machine under the actual command. Watch CPU use, memory, temperature, disk space and upload throughput during a test. Hardware acceleration can reduce processor load, but its availability and FFmpeg configuration vary. Do not select a hardware encoder merely because the graphics hardware exists; verify that the installed build exposes it and that the resulting stream meets YouTube’s requirements.
The network must support the combined upload rate with the recommended headroom. A speed test is useful, but it is only a snapshot. Test at the time of day when the channel will run, and observe whether other household or office activity competes for the connection. YouTube specifically recommends running a speed test to test your upload bitrate.
A dedicated always-on computer, a rented host, or a managed cloud workflow can each be reasonable in different circumstances. A personal computer may be inexpensive if it is already available, but it remains exposed to local power, Wi-Fi and household interruptions. A remote host avoids leaving your main computer on, but it introduces hosting administration, recurring cost and another place where credentials must be protected.
If the main difficulty is keeping a computer awake and restarting a process after a failure, StreamNeo removes that particular operational burden by accepting the uploaded video and YouTube credentials once, then keeping the YouTube broadcast running and monitored while your own computer is switched off. It remains your responsibility to confirm that the content, account and stream settings are appropriate.
For a source such as daily prayer or devotional programming, compare this technical workflow with the editorial decisions in how to stream morning aarti and bhajans all day. The delivery method is only one part of keeping an always-on channel useful.
Test, monitor and recover from interruptions
Run a short private or unlisted test before committing to a public 24/7 schedule. Check the source from beginning to end, observe the loop point, listen for audio, and watch the stream from a different device. Confirm that a phone on a separate connection can load the watch page and that the image remains stable when the source contains motion.
Record the details of a successful test: FFmpeg version, available encoders, source properties, output settings, host operating-system settings and the exact YouTube event configuration. This gives you a known starting point when an update or machine replacement changes the result.
A continuous FFmpeg process needs supervision if you expect it to recover from process failure. On Linux, a service manager can start the process at boot and restart it after a failure. On another operating system, you may use its scheduled-task or service facilities. These mechanisms can relaunch a process, but they cannot repair a bad stream key, a failed disk, a damaged source or a missing network route.
Network interruptions require a recovery plan. Decide whether the process should exit so a supervisor can restart it, whether you will reconnect manually, and how you will identify a repeated failure rather than creating a rapid restart loop. Test the plan by stopping FFmpeg deliberately and by briefly disconnecting the network in a controlled test.
Monitor both the process and the destination. Useful checks include whether FFmpeg is still running, whether its reported time is advancing, whether the host has enough storage, whether upload traffic is present, and whether YouTube reports a healthy incoming stream. A process can remain open while the connection is no longer delivering useful data.
Do not assume that a 24/7 broadcast becomes one complete replay. YouTube says streams under 12 hours can be automatically archived, while streams longer than 12 hours may not be captured at all. If retaining the programme matters, arrange an independent local or remote recording and rotation plan, then test that plan separately. Storage will grow, and recording can add processing or disk-load pressure.
You should also decide what viewers see after a failure. A reconnect may resume the same event, create a new session, or require an action in Live Control Room depending on the failure and settings. Keep the stream key private, document the recovery steps, and make the process simple enough to follow at three in the morning. The 3am failure checklist is useful for turning that response into a written routine.
A single long broadcast is not always the best editorial choice. If you need to replace the file, refresh a news loop or preserve separate replays, planned sessions may be easier to manage than one process that runs indefinitely. If the purpose is simply to provide uninterrupted ambience, test the long-running approach and make sure its archive limitations are acceptable.
A practical decision table
Use the following as a planning guide, then check YouTube’s current settings for the exact combination you select.
| Decision | Lower-demand starting point | Higher-demand choice | What to verify |
|---|---|---|---|
| Codec | H.264 if it is available and reliable in your build | HEVC or AV1 where your build and host support them | Encoder availability, CPU or hardware load, YouTube guidance |
| Resolution and frame rate | 720p at the source’s suitable frame rate | 1080p30 or 1080p60 when the source and connection justify it | Source detail, motion, upload headroom |
| Keyframes | A two-second interval | The same duration at a higher frame rate, not the same frame count | Frame rate and YouTube’s maximum interval guidance |
| Audio | AAC stereo at the recommended setting | A different supported audio choice only after testing | Sample rate, loudness, clipping and channel layout |
| Host | Existing computer with tested power and sleep settings | Dedicated or remote host with supervision | Heat, updates, storage, restart behaviour |
| Recovery | Manual reconnect procedure | Supervisor plus documented recovery and independent recording | Whether each failure mode was tested |
The lower-demand column is not a claim that the settings will work for every source or account. It is a way to narrow the first test. A detailed 720p video may need more bitrate than a mostly static image, while a simple file can still fail if its audio or frame timing is unusual.
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 FFmpeg loop one MP4 forever on YouTube?
Yes, FFmpeg has input-loop options that can repeat a file, and -re can pace file input at its native rate. The exact syntax depends on the installed FFmpeg build, so test the command and watch the transition between loops before using it publicly.
What bitrate should I use for a 24/7 stream?
Use YouTube’s current recommendation for your selected codec, resolution and frame rate rather than choosing one universal number. You also need upload headroom; if the connection cannot sustain the chosen rate reliably, reduce the output demand and test again.
Does FFmpeg automatically restart after an internet outage?
The basic publishing command does not provide a complete recovery system. A service manager or other supervisor can restart a failed process, but you still need to test reconnect behaviour and account for failures involving the host, credentials, source file or network.
Will YouTube save the whole 24/7 broadcast as a replay?
Do not rely on that. YouTube states that streams longer than 12 hours may not be captured at all, so use a separately tested recording and rotation plan if preserving the broadcast is important.