A 24/7 YouTube stream from an MP4 file needs three things: a YouTube encoder stream, an FFmpeg process that reads the file in real time, and an input whose video and audio settings YouTube accepts. FFmpeg can repeat one file indefinitely, but the loop does not make the process or the broadcast immune to network failures, host restarts or YouTube limits.
For a compatible MP4, the shortest useful command uses -re to pace playback and -stream_loop -1 to repeat the input. You can copy the existing audio and video without re-encoding, but only when the codecs and parameters already match the output requirements. Otherwise, re-encode before sending the stream.
Prepare the MP4 and YouTube stream
Start by making a copy of the MP4 you intend to use as the source. Check its duration, picture, sound, frame rate and codecs before you build the live command. A devotional video, music visualiser, study loop or product demonstration may play correctly in a media player while still being unsuitable for a particular live encoder configuration.
Your YouTube channel must be eligible for live streaming. YouTube’s current getting-started guidance says the channel must be verified, must not have had a live-stream restriction in the previous 90 days, and requires streamers to be at least 16. Check the current YouTube live-streaming requirements before planning an unattended broadcast, because account status and platform rules can change.
In YouTube Studio, open the Live Control Room and create or select an encoder stream. YouTube provides the stream URL and stream key for that configuration. They are not universal values that can be copied from another channel, and the key should be treated like a password. If it is exposed in a screenshot, script, support ticket or public repository, reset it in the Live Control Room before using it again. YouTube explains the encoder setup and stream-key process in its live streaming setup guidance.
Use the exact ingest URL shown for your stream. The command later in this guide uses a placeholder rather than a working destination. In many cases, the secure form is an RTMPS endpoint. YouTube recommends RTMPS, which carries RTMP over a connection protected by TLS or SSL. That protects the connection between FFmpeg and the ingest service, but it does not change the requirements for the media inside the stream.
Before starting, decide whether the MP4 itself is your only copy. A long-running live process can fail, and YouTube’s automatic archive behaviour has an important boundary described later. Keep the original file and, if the programme matters, consider making a separate local recording rather than relying on the eventual live archive.
Understand real-time input and infinite looping
An MP4 is normally read as quickly as the computer can decode it. That is useful when converting a file, but it is not what you want for a live broadcast. FFmpeg’s -re option reads the input at its native frame rate, so a ten-minute file takes roughly ten minutes to pass through the input rather than being sent to YouTube in a burst.
The -stream_loop -1 option tells FFmpeg to repeat the input indefinitely. The value -1 means an unlimited number of loops. When the file reaches its end, FFmpeg opens it again and continues producing media for the output. This is a file loop, not a playlist manager: it repeats that input file and does not automatically select the next MP4 in a folder.
Together, the options establish the basic behaviour:
-repaces file input in real time.-stream_loop -1repeats the input without a planned end.-i input.mp4identifies the source file.- The output options decide whether the streams are copied or re-encoded.
-f flvselects the container format commonly used for RTMP and RTMPS publishing.
The process still depends on the computer or host running it. If FFmpeg exits, the operating system restarts, the file becomes unavailable, or the network connection fails, the YouTube broadcast can stop even though the command contains an infinite loop. A continuously running process is not the same as a continuously delivered stream.
The loop boundary can also reveal source problems. A file may have unusual timestamps, a variable frame rate or audio that does not begin and end cleanly. Test at least one complete loop before leaving the stream unattended. Listen at the point where the file restarts and watch for a frozen frame, a brief silence or a sudden change in timing.
Use a basic FFmpeg command
For a source that is already compatible with the chosen YouTube output, use this command shape:
ffmpeg -re -stream_loop -1 -i input.mp4 -c:v copy -c:a copy -f flv "rtmps://YOUTUBE_INGEST_URL/STREAM_KEY"
Replace input.mp4 with the real path to the file. Replace the complete destination with the stream URL and key shown in YouTube Studio. Do not include the placeholder text, and do not publish your actual key in a tutorial, screenshot or shell-history example.
-c:v copy copies the video stream without decoding and encoding it again. -c:a copy does the same for audio. This reduces the amount of encoding work, but it gives you no opportunity to correct an unsuitable codec, frame rate, bitrate, keyframe pattern or audio format. Copy mode is therefore conditional, not a general shortcut for every MP4.
The output format is important. An MP4 file is a storage container, while the YouTube destination expects a live transport format. FFmpeg reads the streams from the MP4 and places them in the FLV output used by the RTMP-family connection. Changing the output container does not automatically make incompatible streams acceptable.
You can add a log file when operating the command unattended:
ffmpeg -re -stream_loop -1 -i input.mp4 -c:v copy -c:a copy -f flv "rtmps://YOUTUBE_INGEST_URL/STREAM_KEY" 2> ffmpeg-live.log
Keep the log somewhere with enough free space, or rotate it using the facilities of the operating system. A log can show whether FFmpeg failed to open the input, lost the connection, encountered a timestamp problem or stopped for another reason. It is more useful than discovering only that the YouTube preview has gone offline.
If the stream needs fixed output settings, re-encode instead of copying. For example, this is a starting pattern for an H.264 and AAC output at 1080p30:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -b:v 5M -r 30 -g 60 -keyint_min 60 \
-c:a aac -b:a 128k -f flv \
"rtmps://YOUTUBE_INGEST_URL/STREAM_KEY"
Treat those values as an example for a 1080p30 H.264 output, not as a universal command. YouTube’s current encoder table gives H.264 1080p30 a recommended video bitrate of 5 Mbps and recommends a 2-second keyframe interval, with no interval longer than 4 seconds. The correct bitrate varies with codec, resolution and frame rate. The encoder workload also depends on the source and the computer.
The -g 60 and -keyint_min 60 values correspond to a 2-second interval at 30 frames per second. If you use a different frame rate, adjust the keyframe values to match the intended interval. Confirm the output against YouTube’s encoder settings, bitrate and resolution table, rather than copying settings designed for another stream.
Check stream compatibility before copying
Stream copy works when the streams already meet the requirements of the destination. The .mp4 ending tells you the container, not whether the video is H.264, H.265, AV1 or another codec, and not whether the audio is AAC, MP3 or something else. Use FFmpeg’s probing tools or another trusted media inspector to record the actual codec, frame rate, dimensions, bitrate, channel layout and timing.
YouTube’s current RTMP and RTMPS encoder guidance lists H.264, H.265/HEVC and AV1 video, up to 60 frames per second, and AAC or MP3 audio. It also describes constant bitrate operation and recommends a 2-second keyframe interval. Those requirements should be checked against the selected output, not merely against the filename or the fact that the file plays locally.
The following comparison explains the practical choice:
| Output approach | Main benefit | Condition or cost |
|---|---|---|
| Stream copy | Little additional encoding work and no generational re-encoding | The source streams and timing must already suit YouTube and the chosen output |
| Re-encode video and audio | Lets you select codec, bitrate, frame rate and keyframe behaviour | Uses processor resources and can introduce quality loss or a new failure point |
| Prepare a new compatible MP4 first | Separates conversion from the live process | Requires storage for the prepared file and an additional preparation step |
A file may be unsuitable for copy mode even when its video codec is accepted. Check for a variable frame rate, a keyframe interval that does not match the planned output, a bitrate that exceeds the available upload path, or audio parameters that the ingest configuration does not accept. Also look for missing audio, because an intentionally silent video and a broken audio stream are different situations.
Audio and video duration should be considered together. If the audio ends earlier than the picture, the loop may produce silence, an error or timing irregularities at the boundary. If the streams have different start timestamps, the first preview may look acceptable while the repeated boundary gradually exposes a sync problem.
If you need to copy the source, do not add conversion options simply because they appear in another command. Options such as a forced frame rate, scaling, a new pixel format or a video bitrate imply a different output decision and may require re-encoding. Start with inspection, then choose copy mode only when the evidence supports it.
For a long devotional, music or study channel, this check is worth doing before you advertise a schedule. The bitrate checklist for 24/7 720p and 1080p streaming can help you compare the output bitrate with the quality and upload conditions you are planning, but YouTube’s current documentation remains the authority for the ingest settings.
Verify the YouTube preview and health
Start the FFmpeg process while the Live Control Room is open. YouTube should receive the signal and show a preview before you make the broadcast public, depending on the stream workflow selected in Studio. Use that preview to check the first minute of picture and sound rather than assuming that a successful FFmpeg connection means the audience is receiving a healthy programme.
Look for the following in the preview:
- The picture has the expected dimensions and is not cropped or stretched.
- Motion is continuous rather than stuttering or freezing.
- Speech, music or ambience is audible without clipping.
- Audio stays aligned with the picture.
- The stream health indicator does not report a sustained bitrate, keyframe or network problem.
YouTube recommends testing movement and sound and monitoring audio and video quality. Follow its streaming tips for testing and monitoring from the same host and network that will run the unattended process. A test performed on a different broadband connection may hide the upload or routing issue that appears overnight.
Watch the transition from the first copy of the file to the second. This is the point at which timestamp or end-of-file issues become visible. If the preview stops at the end, confirm that -stream_loop -1 is placed as an input option before -i input.mp4, and check the FFmpeg log for an error at the loop boundary.
The total outgoing bitrate must fit within the upload bandwidth available. YouTube states that the total bitrate being streamed cannot exceed the available upload bandwidth and recommends leaving headroom. Account for video, audio and any connection overhead rather than comparing only the video bitrate with the headline speed of the internet package.
If you see repeated buffering or dropped frames, reduce the output bitrate only after checking the relevant YouTube recommendation for the selected resolution and codec. A lower bitrate may reduce network pressure, but it can also reduce picture quality. If the source cannot be adapted cleanly, re-encode to a configuration suited to the actual connection.
Plan for interruptions and unattended operation
A 24/7 label describes the intended schedule, not a guarantee that one command will survive every fault. The host must remain powered and connected, FFmpeg must remain running, the input file must remain readable, and YouTube must continue accepting the ingest connection. A power cut, system update, router change or expired credential can interrupt the broadcast.
Use a machine that can run the selected workload continuously and prevent sleep or automatic shutdown. If you re-encode, observe processor use and temperature during a full test. If you copy streams, the encoding workload is smaller, but the process still needs reliable storage, networking and operating-system behaviour. Do not assume that a machine capable of playing the MP4 locally will automatically be a dependable unattended encoder host.
Consider how FFmpeg will be started again after an ordinary process failure. A service manager, scheduled task or carefully configured restart wrapper can launch it again, but these mechanisms belong to the operating system and should be tested separately. A retry feature can reconnect after a temporary network problem; it does not guarantee an uninterrupted event and does not replace automatic restart after FFmpeg exits.
FFmpeg’s FIFO output documentation describes recovery settings that can retry an output after a temporary failure. Treat that as a recovery aid rather than a promise. You still need to test the behaviour with the actual ingest URL, network and host, and you need to decide what should happen if the connection remains unavailable.
Keep the stream key out of public scripts and restrict access to the account and host that need it. Record the exact command in a protected location, with the key supplied through a safer configuration method where practical. If you later change the stream in YouTube Studio, confirm whether the URL, key or event settings have changed before restarting FFmpeg.
If maintaining a machine, process monitor and network path is the part you do not want to operate overnight, StreamNeo removes that specific burden by letting you upload the video, add your YouTube stream key and leave the broadcast running while your own computer is switched off, with monitoring and automatic restart if it drops. It remains a YouTube-only workflow, and you should still check your channel’s content and live-stream responsibilities yourself.
For a more detailed overnight checklist, see how to keep a YouTube church stream running overnight. The same operational questions apply to a bhajan loop, local information channel, study station or small-business product stream: who notices an interruption, who can reset the key, and what happens when the host is unavailable.
Plan around YouTube’s archive limits
Do not assume that a single 24/7 live event will become one complete, permanent YouTube video. YouTube’s encoder instructions say streams under 12 hours are automatically archived. They do not promise automatic archiving for a stream lasting 12 hours or longer.
That distinction matters if the live programme contains music, lessons, news material or a product demonstration that you need to preserve. A stream can be visible to viewers during the event and still not produce the complete archive you expected. The loop command controls what FFmpeg sends; it does not control YouTube’s retention or archive behaviour.
If a durable copy matters, record locally as a separate process and check the resulting files. Keep enough storage for the planned recording, and decide whether one very large file or smaller time-based files are easier to verify and retain. Do not let the recording consume the same storage space needed for the source, logs or operating system.
You should also decide how a future viewer will understand a repeating file. A continuous live page may not show where one cycle begins, and a long archive may be difficult to search. A title or description can explain the schedule, but it cannot compensate for missing sections after an interruption. If you need separate episodes, announcements or chapters, a single infinite MP4 loop may not be the right editorial structure.
Finally, check the current YouTube guidance before committing to a long event. The platform’s rules and product behaviour can change, and a process that works technically may still be unsuitable for your content, channel settings or planned archive. The FFmpeg approach for rotating through several videos is more suitable when repeating one file is not enough, but it introduces its own playlist and transition checks.
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
Does -stream_loop -1 make an MP4 play forever?
It tells FFmpeg to repeat the input indefinitely, while -re paces file input at its native frame rate. It does not keep the process alive after a crash, repair a damaged file or restore a network connection that remains unavailable.
Can I use -c:v copy -c:a copy with any MP4?
No. MP4 is a container, not a guarantee that the codecs, frame rate, bitrate, keyframe interval, timestamps and audio parameters suit YouTube. Inspect the file first, then re-encode when the source does not match the selected YouTube output.
Where do I get the YouTube URL and stream key?
Create or select an encoder stream in YouTube Studio and copy the URL and key shown for that stream. They are account-specific credentials, so keep them private and reset the key if it is exposed.
Will YouTube automatically save a 24/7 stream as one archive?
YouTube documents automatic archiving for encoder streams under 12 hours, but does not promise the same behaviour for streams lasting 12 hours or longer. If you need a complete copy, make and verify a separate local recording rather than relying on one long YouTube archive.