For a 24/7 prerecorded YouTube stream, start with YouTube’s live-ingestion guidance rather than a universal FFmpeg preset. For a conventional 1080p30 H.264 stream, that means CBR, a two-second keyframe interval, AAC audio at 128 kbps, and a bitrate chosen around your sustained upload capacity and encoder load.
The command -stream_loop -1 can repeat one input indefinitely, but it does not solve network loss, an FFmpeg process failure, or every YouTube ingest problem. Treat looping, encoding, publishing, monitoring, and recovery as separate parts of the service.
Why there is no universal best bitrate
The best FFmpeg settings depend on what you are sending and what your machine and connection can sustain. A devotional image with slow movement, a lofi animation, a local news loop with scrolling text, and a cricket replay place different demands on the encoder even when they share the same output resolution.
You also need to distinguish between a bitrate that YouTube lists as a minimum and one it lists as recommended. For 1080p30 H.264, YouTube’s current live encoder table lists 5 Mbps as the minimum and 14 Mbps as the recommended video bitrate. A 5 Mbps starting point can be practical for a modest, stable stream, but it is not the same as YouTube’s recommended value.
Your available upload speed is another constraint. A setting is not suitable merely because an online speed test briefly reaches it. The connection must carry the video bitrate, audio, protocol overhead, and ordinary variation for as long as the broadcast runs. YouTube advises leaving approximately 20% bandwidth room and testing with similar audio and motion. See the data use of a 24/7 FFmpeg stream before committing to a connection or hosting plan.
Finally, higher bitrate can increase the amount of data that must be uploaded without fixing a weak source or an overloaded encoder. If the input is already a clean 720p file, forcing it to 1080p does not create new detail. It can add scaling work and make the path less forgiving.
Start with YouTube’s live-ingestion table
Use the row that matches the codec, resolution, and frame rate you are actually sending. The figures below are from YouTube’s live encoder settings guidance, accessed in October 2026. They are ingestion guidance, not a promise that every viewer will receive the same quality.
| FFmpeg output | H.264 video bitrate | Practical interpretation |
|---|---|---|
| 1080p30 | 5 Mbps minimum; 14 Mbps recommended | Use 5 Mbps as a modest starting point only when the content and connection suit it. Consider 14 Mbps when sustained capacity and encoder headroom support it. |
| 720p30 | 3 Mbps minimum; 8 Mbps recommended | Useful where upload capacity is lower or 1080p encoding is unnecessarily demanding. |
The table applies to the H.264 row when you use libx264. Do not copy a number from an AV1 or H.265 column into an H.264 command. YouTube lists different guidance for different incoming codecs, and the codec changes both compression behaviour and encoder requirements.
YouTube recommends RTMPS where supported. Its live encoder settings guidance also describes CBR, keyframe timing, supported codecs, audio settings, and colour recommendations. Keep that page available when you change resolution or codec because the published table can change.
For a standard SDR H.264 output, the important target settings are progressive video, Rec. 709 colour, 8-bit SDR, AAC stereo audio, and a two-second keyframe interval. At 30 frames per second, two seconds is 60 frames, which is why the example below uses -g 60.
Choose 1080p30 when capacity supports it
1080p30 is the sensible choice when your source is genuinely 1080p, your viewers benefit from readable detail, and your upload path can sustain the selected bitrate with headroom. It can suit local news graphics, teaching slides, scripture text, music visualisers, and footage where small text or fine movement matters.
For libx264, a straightforward illustrative baseline is:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 5M -maxrate 5M -bufsize 10M \
-pix_fmt yuv420p -r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "YOUTUBE_RTMPS_INGEST_URL/STREAM_KEY"
Replace input.mp4, the ingest URL, and the stream key with your own values. The command assumes an installed FFmpeg build with libx264 and AAC support, and a conventional 1920x1080, 30 fps input. It is an example for testing, not a tested command for every operating system or FFmpeg build.
The 5 Mbps value here is the published H.264 minimum for 1080p30, not YouTube’s recommended value. If your content has sustained motion and your connection can reliably support the higher target, change the video bitrate and -maxrate together rather than raising one and leaving the other behind. A higher setting is only useful if the source, encoder, upload path, and ingest remain stable.
-preset veryfast is an illustrative CPU trade-off. A slower preset may compress more efficiently but can increase encoder load. A faster preset may reduce CPU pressure while producing less efficient output at the same visual quality. YouTube does not prescribe this particular preset, so watch the machine rather than treating it as a rule.
Likewise, -bufsize 10M, -pix_fmt yuv420p, -ar 44100, and -sc_threshold 0 are example FFmpeg choices. They are not all mandatory YouTube values. Confirm that your local build accepts the options and that the output properties match the actual input and target.
Keep the stream key private. YouTube’s encoder setup instructions tell you where to copy the stream URL and key from Live Control Room. Do not leave the key in a public script, screenshot, repository, or support ticket.
Consider 720p30 for lower bandwidth
720p30 is not a failed version of 1080p30. It is often the more reliable choice when the source is 1280x720, the connection has limited upload capacity, or the encoding machine struggles with a larger frame. For a simple bhajan loop, black-screen sleep stream, study timer, or station graphic, stable 720p can be more useful than an unstable 1080p feed.
YouTube’s current H.264 guidance lists 3 Mbps as the minimum and 8 Mbps as the recommended bitrate for 720p30. That gives you a conditional choice: use the lower figure only when your content and testing support it, and move towards the recommended figure when sustained bandwidth is available and the additional data improves the result.
A 720p output can also reduce scaling work if the source is already 720p. If your source is 1080p but the connection cannot sustain a suitable 1080p stream, scaling down deliberately is usually clearer than allowing an overloaded or fluctuating 1080p encode to continue. Test the scaled output, especially where the video contains captions, ticker text, or fine line art.
To adapt the example, change the output dimensions explicitly if the input does not already match them. For example, add a video filter such as -vf scale=1280:720 and choose a 30 fps output. Do not add scaling merely because 720p is the target if the source already has the correct dimensions. Every additional operation is worth checking on the actual machine.
The right decision is not “1080p is always better”. It is whether the extra detail survives the complete path. A viewer may see a sharper result from a stable 720p stream than from a 1080p stream that repeatedly falls behind, drops its connection, or produces an unusable preview.
Separate input settings from viewer playback formats
Your FFmpeg command controls the feed you send to YouTube. It does not dictate the final format every viewer receives. YouTube processes the incoming live feed and creates viewer playback formats according to its own systems and the viewer’s device, connection, and selected quality.
That distinction matters when diagnosing complaints such as “my viewers cannot select 1080p”. First confirm what your encoder is actually sending. Then check YouTube Studio’s preview and stream health. A correct 1080p30 input does not mean that every viewer will immediately receive, or be able to select, a 1080p version.
The same applies to frame rate and audio. Sending 30 fps does not force a viewer to watch at 30 fps under every network condition. Sending 128 kbps stereo AAC sets the incoming audio configuration; it does not make a mobile connection immune to buffering.
YouTube supports several incoming video codecs, including H.264, H.265/HEVC, and AV1. H.264 with libx264 is a conservative choice for a broadly understandable FFmpeg setup, but it is not automatically the most efficient choice for every machine. The encoder must be available in your build, and the machine must sustain it continuously.
Do not substitute YouTube’s upload-video bitrate table for its live-ingestion guidance. Uploading a finished file and publishing a live feed are different paths with different considerations. Use the live encoder table for the feed being sent to YouTube.
Test sustained upload and encoder load
A short test can show that a command starts. It cannot show that the same machine and connection will behave through the night. Before making the channel public, run the complete path with the same file type, audio, resolution, frame rate, motion, and bitrate that you plan to use.
Start by checking your FFmpeg version and build. Confirm that libx264, AAC, the selected pixel format, and the output protocol are available. An option copied from a guide may be missing or behave differently in another build.
Then measure the upload path while FFmpeg is actively encoding. YouTube recommends leaving approximately 20% room; its guidance also discusses fitting primary and backup stream bitrates within available outbound capacity when both are in use. The connection should have capacity beyond the nominal video bitrate, not just equal to it.
Look at three things during the test:
- Encoder load: CPU use, thermal throttling, dropped frames, and whether FFmpeg reports that it is falling behind.
- Upload stability: sustained output rate, packet loss, changing latency, and whether the connection briefly collapses under ordinary household or office traffic.
- YouTube ingest: preview behaviour, stream health, incoming resolution, audio, and warnings in Live Control Room.
Test with a section of content that represents the difficult part of the channel. A still devotional image is not a useful stress test for a news loop with animated lower thirds. A quiet lofi scene is not a useful test for a video containing rapid cuts. YouTube specifically advises testing with similar audio and motion.
Use an unlisted or test event where appropriate, and check the watch page from a separate device. The guide to testing a live stream without going public is useful when you want to inspect the viewer experience without announcing the broadcast to your audience.
Do not judge success only by whether FFmpeg remains open. A process can still be running while YouTube receives an irregular feed, audio is missing, or the encoder is producing frames too slowly. The preview and stream-health indicators are part of the test.
Adjust for motion, source quality, and stability
Bitrate should follow the material as well as the resolution. A fixed camera, a dark background, and occasional text changes may compress comfortably at a lower rate than a sports replay or a full-screen screen recording. This does not create a new official YouTube limit; it is a practical reason to test the content you will actually broadcast.
Keep the frame rate honest. If the source is 30 fps, outputting 30 fps avoids inventing additional frames. If the source has a different frame rate, decide deliberately whether to preserve it or convert it. The -r 30 option in the example is an output choice, not proof that every input should be forced to 30 fps.
The same principle applies to resolution. Do not upscale a small source simply to put “1080p” in the stream settings. Scaling can make text softer while adding work for the encoder. Use the dimensions that suit the source and the viewing purpose, then confirm how YouTube reports the incoming feed.
A two-second keyframe interval is a useful operational target because it gives the ingest service regular access points. At 30 fps, use a GOP of 60 frames. YouTube recommends two seconds and says not to exceed four seconds. Scene-change behaviour can complicate exact GOP timing, so test the resulting stream rather than assuming the command expresses every encoder detail perfectly.
If the feed is unstable, lowering the bitrate may help only when the upload path is the limiting factor. If CPU is saturated, a faster preset, a lower output resolution, or hardware encoding may be the relevant change. If the source file or audio pipeline is defective, changing bitrate will not repair it.
For content rotation, do not assume that looping one file is equivalent to a playlist. Multiple files may differ in dimensions, frame rates, audio layouts, timestamps, or colour properties. The playlist workflow for looping live streams explains why transitions need their own testing.
Understand what “24/7” requires after the command starts
-stream_loop -1 is an input option. Placed before the relevant -i, it tells FFmpeg to repeat that finite input indefinitely. It handles media repetition only. The -re option reads a file at its native rate, which is useful when simulating live input from a file; it is not a universal requirement for an actual live capture device.
There are at least three separate continuity problems:
- The media reaches its end and needs to repeat.
- The output connection encounters a temporary error.
- The host, network, FFmpeg process, or YouTube ingest needs supervision or replacement.
FFmpeg’s official documentation includes a FIFO output example using -f fifo -fifo_format flv, -attempt_recovery 1, and -recovery_wait_time 1. That example is a recovery pattern to examine and test, not a guarantee that YouTube will preserve one player session or that every output error can be repaired.
Do not copy HTTP input options such as -reconnect onto a YouTube RTMP or RTMPS output and assume they provide universal publishing recovery. Protocol options are not interchangeable. Check the official FFmpeg documentation for your build, then test the chosen behaviour against the actual ingest endpoint.
A supervised unattended setup needs a restart policy, visible logs, alerting, and a tested fallback. Stop the primary encoder or disconnect its network during a controlled test and confirm what viewers see when a backup path is used. Reconnection can still create a gap, and a restarted broadcast may not behave like an uninterrupted player session.
For operators who do not want a local machine running overnight, an uploaded file can be sent to YouTube continuously from the cloud, with the computer switched off and automatic monitoring and restart handling. That removes the need to keep a home laptop awake, but you still need to test the content, stream key, YouTube settings, and channel policy yourself.
Preflight checks before publishing
Use this sequence before treating the channel as an always-on service:
- Confirm the source has the intended resolution, frame rate, audio track, and duration.
- Check that your FFmpeg build contains the selected video encoder, AAC support, and output protocol.
- Choose the H.264 row that matches 1080p30 or 720p30 rather than borrowing a number from another codec.
- Calculate whether the bitrate plus audio and headroom fits the sustained upload path.
- Run the full command with representative motion and inspect CPU, dropped frames, and timing.
- Check Live Control Room preview, incoming resolution, audio, and stream health.
- Watch from a separate device and network where possible.
- Keep the stream key out of scripts that will be shared or committed.
- Test what happens when the network is interrupted and when FFmpeg is stopped.
- Decide how alerts, restarts, and backup publishing will work before the first unattended night.
For a channel built from existing uploads, also check the rights and YouTube policies for every file. A 24/7 configuration does not grant permission to use music, television footage, sports clips, or other material, and it does not guarantee monetisation. If the channel uses archived broadcasts, remember that YouTube’s encoder setup guidance says streams under 12 hours are automatically archived. Do not assume that statement creates one complete archive for a broadcast that runs continuously beyond that duration.
When a feed keeps disconnecting, compare the symptoms rather than immediately changing every FFmpeg flag. The specific fixes for yellow or red stream health can help separate an upload problem from an encoder or YouTube configuration problem.
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
What FFmpeg settings do I need for 24/7 YouTube streaming?
For a conventional 1080p30 H.264 feed, begin with CBR, a two-second keyframe interval, AAC stereo at 128 kbps, and a bitrate selected from YouTube’s live-ingestion table. Add -stream_loop -1 when repeating a finite file, but test supervision and recovery separately because looping does not make the network or process failure-proof.
How do I loop a video forever on YouTube Live with FFmpeg?
Use -stream_loop -1 before the input option, such as ffmpeg -re -stream_loop -1 -i input.mp4. This repeats one input indefinitely. It does not provide playlist transitions, repair every output error, or guarantee that YouTube keeps one continuous viewer session.
What bitrate should I use for 1080p live streaming to YouTube?
For 1080p30 H.264, YouTube’s current live guidance lists 5 Mbps as the minimum and 14 Mbps as the recommended video bitrate. Choose between them based on sustained upload capacity, headroom, source motion, and encoder load, then validate the result in Live Control Room.
How do I keep an FFmpeg YouTube stream from stopping?
First identify whether the problem is the input ending, encoder overload, network loss, or an output and ingest failure. Use supervision, alerting, and a tested restart or backup plan, and inspect YouTube’s stream health rather than relying only on the fact that the FFmpeg process is still running.