For a 24/7 YouTube loop stream, choose the bitrate for the stream's resolution, frame rate and video codec. YouTube does not publish a separate bitrate category for looping broadcasts.
A practical H.264 starting point is 8 Mbps for 720p30 or 720p60, 14 Mbps for 1080p30, and 17 Mbps for 1080p60. If your encoder supports AV1 or H.265, YouTube's corresponding recommendations are lower, but your source, installed FFmpeg build and sustained upload connection still need to support the complete setup.
What -stream_loop -1 does
FFmpeg normally reaches the end of a local video and exits. That is suitable for a file conversion, but not for an always-on channel. The -stream_loop -1 option tells FFmpeg to repeat the input indefinitely. The value -1 means no fixed loop count.
The important detail is its position. -stream_loop -1 is an input option, so it belongs before the input declaration, immediately before -i or alongside the other options that describe the input. In this pattern:
ffmpeg -stream_loop -1 -re -i "input.mp4" ...
FFmpeg applies the looping instruction to input.mp4. Placing it after -i changes how FFmpeg parses the command and may mean that the option is rejected, applied to the wrong part of the command, or behaves differently from what you intended, depending on the option and build.
This is separate from the YouTube bitrate. Looping controls what happens when the file reaches its end. Bitrate controls how much encoded video and audio the encoder sends to YouTube while the file is playing.
A looped source also needs to join cleanly. If the last frame and first frame differ sharply, viewers may see a jump, a brief audio gap or an obvious restart. Bitrate cannot remove that transition. Check the source itself, especially if you are preparing a devotional video, a bhajan playlist, an ambience background or a local information loop.
If the loop is part of a wider launch rather than a permanent channel, the workflow may be different. A live countdown stream guide can help when the broadcast needs a planned opening and closing sequence rather than an endless file.
Put input options before -i
FFmpeg commands are easier to troubleshoot when you think of them in three parts:
- Options that describe or control the input file.
- The input declaration, such as
-i "input.mp4". - Options that control encoding and the output destination.
For a local file, -stream_loop -1 and -re are input-side options. They should appear before -i. Video codec, bitrate, frame rate, audio codec and destination format are output-side choices and normally appear after the input.
That order is not a cosmetic preference. FFmpeg has input and output options, and an option can apply to the next input or output in the command. The FFmpeg documentation describes this command-line structure and the distinction between input and output handling.
A useful way to read the beginning of a command is:
ffmpeg [input options] -i [input file] [output options] [destination]
For a looped local file, that becomes:
ffmpeg -stream_loop -1 -re -i "input.mp4" [encoding options] [YouTube destination]
Do not assume that copying a command from another setup makes every option valid on your computer. FFmpeg builds can include different encoders, and the name of an available encoder must match the installed build. Run ffmpeg -encoders locally if you are comfortable using the command line, or check the application documentation if another program is assembling the command for you.
If you are deciding between running FFmpeg or using a hosted workflow, compare the operational difference rather than only the initial command. The discussion of OBS and a cloud service for a 24/7 church stream is relevant because a local encoder depends on the computer, power, network and software remaining available.
Add -re when the input is a local file
The -re option asks FFmpeg to read a file at its native playback rate instead of sending it as quickly as the machine can process it. For a local prerecorded video being used as a live source, that is normally the behaviour you want.
Without rate control, a fast computer may read and encode a file much faster than real time. You could then send a burst of data to YouTube rather than a steady stream. The result is not a useful 24/7 broadcast, even if the command appears to be processing successfully.
Use -re for a local file that is being presented as live input. Do not blindly add it to every input type. A real-time capture device or another live source is already producing data according to a clock, so applying file-style rate control may be unnecessary or counterproductive.
-re also does not solve upload instability. It regulates how FFmpeg reads the file, while the network connection determines whether the encoded stream can reach YouTube consistently. A file can play at the correct speed and still fail when the upload connection has insufficient sustained capacity.
For a channel built from a long video, listen to the beginning and end of at least one complete pass. Confirm that the audio does not drift, that the final frame is not held unexpectedly, and that the next pass starts as intended. A short command-line test can reveal a malformed file before you spend a night diagnosing the network.
A documented command pattern for YouTube
The following is a pattern to adapt, not a tested universal preset. It assumes a local file, an H.264 encoder named libx264, stereo AAC audio and a 1080p30 target. Your build may use a different encoder name, and the source may need scaling, frame-rate conversion or different audio handling.
ffmpeg -stream_loop -1 -re -i "input.mp4" \
-c:v libx264 -b:v 14M -maxrate 14M -bufsize 28M \
-r 30 -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"
The option order is the part to preserve. -stream_loop -1 and -re come before -i. The encoder and bitrate options come after the input. The destination is last. Replace the placeholder stream key with the key from YouTube Live Control Room, and treat that key as sensitive because it is the credential used by your encoder to send to the channel.
In this example, -b:v 14M reflects YouTube's H.264 recommendation for 1080p30. -maxrate and -bufsize are shown as matching rate-control values for this example, but they are not a guarantee that every source or FFmpeg build will behave identically. -g 60 represents a two-second keyframe interval at 30 frames per second. Test the resulting stream rather than treating those values as a universal recipe.
The -f flv output format is commonly used with RTMP or RTMPS destinations. YouTube recommends RTMPS for live streaming. Its live encoder settings guidance also covers supported protocols, codecs, frame rates, bitrate guidance and keyframe intervals.
Your actual stream key and ingest address may be supplied by the software you use. Do not publish the key in a screenshot, paste it into a public support forum or leave it in a shared script. If you believe it has been exposed, use YouTube's current official instructions for replacing or managing the key.
If your source is already encoded in a compatible format and your workflow can copy it without re-encoding, the command may be different. A looped live feed still needs a valid, steady output, so test the complete command with the actual destination rather than assuming that file playback proves the broadcast path works.
Choose the bitrate from the actual format
YouTube's live-encoder recommendations are organised by ingestion resolution, frame rate and codec. The table below reproduces the relevant recommendations as listed on YouTube's site in September 2026. YouTube's page displays no publication year, so these figures should be treated as current guidance to verify before a production launch, not as a permanent rule.
| Ingestion format | AV1 or H.265 recommended bitrate | H.264 recommended bitrate |
|---|---|---|
| 720p30 | 6 Mbps | 8 Mbps |
| 720p60 | 6 Mbps | 8 Mbps |
| 1080p30 | 10 Mbps | 14 Mbps |
| 1080p60 | 12 Mbps | 17 Mbps |
| 1440p30 | 15 Mbps | 21 Mbps |
| 1440p60 | 24 Mbps | 34 Mbps |
| 2160p30 | 30 Mbps | 42 Mbps |
| 2160p60 | 35 Mbps | 50 Mbps |
Choose the row that matches what you actually send to YouTube. Do not choose 1080p30 because the source file is large, then send a 720p stream and keep the 1080p figure by habit. The bitrate applies to the encoded output, not to the filename, editing timeline or original camera resolution.
For a mostly static devotional image with gentle movement, 1080p30 may be a sensible format to evaluate. If the source is 30 fps, sending it at 60 fps does not create additional motion detail. It may increase processing and bandwidth requirements without improving the material viewers are watching.
For a channel with limited upload capacity, 720p30 H.264 at 8 Mbps is an official lower-resolution option. That may be more dependable than choosing 1080p60 and repeatedly exhausting the connection. A stable lower-resolution stream is more useful than a higher-resolution plan that drops whenever another person uses the network.
YouTube also lists minimums, but a minimum is not the same as the recommended target. For example, at 1080p30 its listed minimum is 5 Mbps for H.264 and 4 Mbps for AV1 or H.265, as listed on YouTube's site in September 2026. Starting at the recommended row gives you a clearer reference point; moving below it should be a deliberate test based on the source and connection.
Do not confuse these live-ingestion figures with a viewer's playback bitrate or with the bitrate for uploading a finished video. The encoder sends one feed to YouTube, and YouTube processes that live feed into versions for different viewers and devices. A viewer on a mobile connection may not receive the same stream representation as a viewer on a fast broadband connection.
Match the codec and encoding settings
YouTube lists H.264, H.265 and AV1 as live video codec choices, but availability depends on the encoder software and hardware you are using. The name libx264 in the example is not a promise that every FFmpeg installation includes it. If the encoder is missing, the command will fail before a bitrate decision matters.
The codec and bitrate columns must stay together. At 1080p30, the published recommendation is 14 Mbps for H.264 and 10 Mbps for AV1 or H.265, as listed on YouTube's site in September 2026. Do not select the AV1 number while encoding H.264 simply because it is lower.
YouTube recommends constant bitrate encoding for live video and a keyframe interval of two seconds, with a maximum of four seconds, as listed on YouTube's site in September 2026. At 30 frames per second, a two-second interval corresponds to 60 frames, which is why the example uses -g 60. If you change the frame rate, revisit the keyframe value rather than copying it unchanged.
For stereo audio, YouTube lists AAC or MP3, a 44.1 kHz sample rate and 128 kbps, as listed on YouTube's site in September 2026. The example uses AAC at those stereo settings. If your source has a different channel layout, unusually high sample rate or multiple audio tracks, test the output and check what the encoder is actually sending.
These are platform settings, not a substitute for checking the source. A source with variable frame rate, damaged timestamps, an unsupported pixel format or an audio track that ends before the video may need preparation first. A command can be syntactically correct and still produce an unsuitable broadcast.
If your channel uses music, confirm that you have the necessary rights and review YouTube's current policies before relying on a long-running loop. For example, a 24/7 Krishna bhajan stream guide deals with the practical context of devotional programming, but no bitrate setting changes the rights position for the material you use.
Leave upload headroom for the whole feed
Your planned video bitrate is not the only traffic on the connection. Audio, protocol overhead and other activity on the same network also consume capacity. YouTube says total streaming bitrate cannot exceed available upload bandwidth and recommends leaving about 20 percent of room, as listed on YouTube's site in September 2026.
Treat that as headroom around the complete stream, not as permission to use the entire result for video. For a 14 Mbps video target, add the audio bitrate and allow room for overhead before comparing the plan with your sustained upload capacity. If other people use the connection for video calls, backups or uploads, their traffic also matters.
A speed-test peak is not the same as a stable overnight upload. Test at the location and time where the encoder will operate, then repeat while normal household or business traffic is active. YouTube's streaming tips recommend checking upload capacity, allowing room and using a reliable connection.
A wired connection can be a practical choice for a fixed encoder because it removes one source of wireless variation, but YouTube's guidance does not make a particular cable, router or connection type a universal requirement. The useful test is whether the actual stream remains healthy under the conditions in which it will run.
For a local computer, also account for power cuts, sleep settings, operating-system updates and accidental restarts. If those risks are difficult to control, a hosted workflow can remove the need to keep your own computer switched on. StreamNeo is designed for the specific pain of uploading the file once, supplying the YouTube stream key and letting the channel run while the computer is off, with monitoring and automatic restart if the broadcast drops.
Test the feed in YouTube Live Control Room
Create or schedule the stream in YouTube Live Control Room, enter the encoder details and wait for the preview before making the broadcast public. Check the incoming resolution, frame rate, codec, audio and stream health rather than relying only on FFmpeg's terminal output.
Test the actual loop, not a different sample file. YouTube's guidance says tests should include audio and movement similar to the intended stream, as listed on YouTube's site in September 2026. For a devotional channel, test the real music mix and transitions. For a study or ambience channel, test the long quiet sections as well as the moving parts.
Watch for dropped frames, unstable upload warnings, missing audio, unexpected scaling and repeated loop boundaries. If the source changes from a detailed scene to a static slide, observe whether the encoder remains stable across that change. Check the beginning of the second pass, since a file can behave correctly at its first start and fail when it loops.
YouTube's live controls also include choices such as latency, DVR and automatic start or stop. These are separate from bitrate. Lower latency can increase buffering for viewers, and it is less important when you are not responding to an audience in real time. Choose those controls for the channel's use case rather than expecting a bitrate change to fix them.
A successful preview is evidence that the current source, command and connection can reach YouTube at that moment. It is not proof that the setup will run indefinitely. Keep monitoring after publication, and check the stream from a viewer's device as well as from the encoder computer.
For troubleshooting after an overnight failure, record the time, stream-health message, encoder log and network state. The guide on why YouTube may end a 24/7 live stream can help separate an encoder issue from a platform, account or content issue. Bitrate is one part of that diagnosis, not the whole explanation.
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
Is there a special bitrate for a 24/7 YouTube loop?
No separate 24/7-loop bitrate is listed in the YouTube live-encoder guidance reviewed. Choose the recommendation for the output resolution, frame rate and codec, then test the actual loop and connection.
Is 1080p30 better than 1080p60 for a loop?
Often, 1080p30 is the more sensible format when the source is 30 fps and movement is limited. YouTube lists 14 Mbps for H.264 at 1080p30 and 17 Mbps at 1080p60, as listed on YouTube's site in September 2026, but the higher frame rate does not add motion that is absent from the source.
Why must -stream_loop -1 come before -i?
It is an input option that tells FFmpeg how to handle the following input file. Putting it before -i makes the intended relationship clear and follows FFmpeg's input-option order.
Will the recommended bitrate guarantee an uninterrupted stream?
No. The recommendation describes the encoded feed, while uninterrupted operation also depends on the source, encoder, computer or hosting arrangement, power and sustained upload connection. Test the actual setup and leave upload headroom before relying on it overnight.