For H.264 SDR ingest, set FFmpeg to 14 Mbps at 1080p30 or 17 Mbps at 1080p60, using the frame rate that matches the source. YouTube also recommends CBR, a two-second keyframe interval, AAC stereo audio and RTMPS; none of those settings guarantees an uninterrupted 24/7 run.
Encoding settings address what FFmpeg sends to YouTube. Continuous operation also depends on a working source, an encoder and host that keep up, and an upload connection with enough capacity. Test representative content and use YouTube’s stream-health feedback before relying on a setup overnight.
Recommended FFmpeg settings for 1080p
The settings below are for H.264 SDR contribution to YouTube Live. YouTube’s encoder recommendations specify the target values; the command later in this section is an example for a looping local file with audio, not a one-size-fits-all recipe. Check the current YouTube encoder settings before putting a stream into regular operation, since platform guidance can change.
| Setting | 1080p30 | 1080p60 | Practical note |
|---|---|---|---|
| Video codec | H.264 | H.264 | libx264 is a software encoder available in some FFmpeg builds. |
| Recommended video bitrate | 14 Mbps | 17 Mbps | YouTube’s recommended H.264 rates, not a guarantee of picture quality or continuity. |
| Rate control | CBR | CBR | Keeps the target video rate constant. |
| Keyframe interval | 2 seconds, 60 frames | 2 seconds, 120 frames | Frame counts follow the selected frame rate. YouTube says not to exceed four seconds. |
| Audio | AAC, stereo, 128 Kbps, 44.1 kHz | Same | Test the actual audio, including any loop transition. |
| Contribution protocol | RTMPS | RTMPS | YouTube recommends RTMPS for the connection to its ingest service. |
| SDR picture | Progressive, square pixels, Rec. 709, 8-bit | Same | Match these to the source and the transformations you apply. |
YouTube also lists advanced H.264 settings of two B-frames, one reference frame and CABAC. They are included in the example, but encoder support and behaviour can depend on your FFmpeg build. The FFmpeg documentation describes the available options; check the documentation for your installed version and encoder rather than assuming every build accepts every flag.
Here is an illustrative command for a compatible local file with audio, looping at 1080p30. Replace the input path and the ingest URL and key with the values shown in YouTube Live Control Room. The URL here is deliberately a placeholder: never publish a real stream key in a script, screenshot or article.
ffmpeg -re -stream_loop -1 -i input.mp4 \\
-vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,fps=30,format=yuv420p" \\
-c:v libx264 -preset veryfast -tune zerolatency \\
-profile:v high -pix_fmt yuv420p \\
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M \\
-g 60 -keyint_min 60 -sc_threshold 0 \\
-bf 2 -refs 1 -coder cabac \\
-color_primaries bt709 -color_trc bt709 -colorspace bt709 \\
-c:a aac -b:a 128k -ar 44100 -ac 2 \\
-f flv "rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY"
For 1080p60, change the filter to fps=60, set -g 120 -keyint_min 120, and use -b:v 17M -minrate 17M -maxrate 17M -bufsize 34M. The buffer sizes in this example are two seconds of the selected target bitrate; they are command choices, not YouTube-mandated values. These changes assume your source really is suited to 60 fps and that the machine can encode it in real time.
The scale-and-pad filter fits the whole input image within 1920 by 1080 and adds bars where the aspect ratio differs. That may be preferable to cropping, but inspect the output for your material. A live camera, a network source, audio-free content, HDR, a hardware encoder or a file intended to play once needs a different command. -preset veryfast is an example, not a benchmark or universal best choice; test sustained encoding on the actual host.
The -re option paces a file input for real-time output. FFmpeg documents it as equivalent to -readrate 1 and cautions against adding it indiscriminately to a real capture device or live network source, where it can contribute to packet loss. For a file that should stop after one play, remove -stream_loop -1. For any source, verify that the input remains available for the intended duration and that a loop does not introduce a noticeable jump or gap.
Choose 30 or 60 fps to match the source
Frame rate is a property of the motion you have, not a quality switch to turn up without consequence. A static devotional image, a lyrics screen or a slowly changing ambience scene may be adequately represented at 30 fps. A source with substantial movement, such as a dance performance or a busy street scene, may benefit from 60 fps if the original footage contains that motion detail.
Converting a 30 fps source to 60 fps does not create genuine motion detail. It asks the encoder to produce more frames without adding new movement from the original recording. Conversely, reducing a genuinely fast-moving 60 fps source to 30 fps can make motion look less smooth. Choose based on representative footage, not on the assumption that the larger number is always better.
There is a practical encoding and network trade-off. YouTube’s recommended H.264 rate is 14 Mbps at 1080p30 and 17 Mbps at 1080p60, and the encoder must process twice as many frames per second at 60 fps. That does not establish how a particular computer will perform; test the actual device, encoder and content together. YouTube lists minimum guidance of 5 Mbps at 1080p30 and 6 Mbps at 1080p60, but a minimum is not the same as the recommended target when capacity permits.
If your source is already 30 fps and mostly still, begin by testing 1080p30. If it is 60 fps with real motion, test 1080p60 and watch both encoder performance and the receiving stream. If unsure, compare a representative section at each source-appropriate setting, including the busiest movement and any text that must remain readable.
Set CBR and a two-second keyframe interval
YouTube recommends constant bitrate encoding for this H.264 ingest profile and a keyframe every two seconds. In FFmpeg, the example uses matching -b:v, -minrate and -maxrate values to request a constant target rate from the encoder. Rate-control details can vary with encoder implementation, so inspect the output and check the documentation for your chosen encoder.
The -g option sets the GOP size in frames. At 30 fps, 60 frames represent two seconds; at 60 fps, 120 frames represent two seconds. -keyint_min is set to the same count in the sample, and -sc_threshold 0 disables scene-cut keyframes in this example so the maximum interval remains predictable. Confirm the behaviour with your encoder build; flags do not make every encoder behave identically.
A two-second interval is a stream-format recommendation, not a way to prevent a process, source or connection from failing. Do not lengthen it to try to make a weak connection reliable. If you have an older desktop, the cost and practical limits of running a 24/7 stream on one are part of the decision alongside the encoding flags.
Configure AAC audio and RTMPS
For this H.264 setup, use AAC audio, stereo, 128 Kbps and 44.1 kHz. The sample expresses these with -c:a aac -b:a 128k -ar 44100 -ac 2. Listen to the encoded output rather than assuming that a successful command means audio is right: check channel balance, level, sync and any silence, clicks or abrupt changes at file-loop boundaries.
If the source has no audio, decide deliberately whether the output should include silence or no audio stream and confirm what YouTube receives. An audio track containing unintended blank input can be as troublesome to viewers as a missing track. Your test should use the same audio path and mix as the eventual broadcast, including any music bed or spoken announcements.
YouTube recommends RTMPS for encrypted contribution. Use the ingest address provided in the channel’s Live Control Room, and keep the stream key private. If the key stops working after account changes, follow the channel-side checks in this guide to troubleshooting a YouTube stream key rather than repeatedly pasting it into public logs or screenshots.
Match bitrate to resolution and frame rate
The recommended 1080p H.264 targets differ by frame rate: 14 Mbps for 30 fps and 17 Mbps for 60 fps. Treat those numbers as YouTube ingest guidance for the specified format, not as a promise of the final viewer experience. Picture complexity, the source itself, encoding behaviour and the viewer’s connection all matter.
The total outgoing stream rate includes audio as well as video and any protocol overhead. YouTube’s streaming tips state that total stream bitrate cannot exceed available upload bandwidth. That means you should evaluate the real connection while the stream is running, not just read a headline speed from an internet package. Other household or business traffic can also compete for upload capacity.
There is no universal upload-headroom percentage in the guidance used here. Leave practical room for ordinary variation rather than assuming the line will continuously deliver its peak rate. If the upload cannot sustain the selected bitrate, consider whether 30 fps or a lower-resolution output is more appropriate for the source and channel. Do not quietly lower the rate and assume the quality is unchanged; compare the resulting picture and stream-health messages.
YouTube lists 5 Mbps and 6 Mbps as minimums for 1080p30 and 1080p60 respectively. These figures are not a target to substitute automatically for the recommended rates; use them as a boundary when assessing whether the upload can support a mode at all, then test the actual output. The higher 60 fps recommendation has consequences for both the encoder and the connection, so it should be chosen for source motion rather than as a default badge of quality.
Test representative picture and audio
YouTube recommends testing before a live stream and using picture and audio representative of the real programme. A static opening slate is not enough if the channel normally shows moving worship, changing captions, a camera feed or rapid cuts. Put the busiest and most visually demanding parts of the planned programme through the intended command and inspect the incoming result.
Look for the correct resolution and frame rate, unexpected bars or cropping, softened fine text, blockiness in motion and colour that differs from the source. Listen at a normal viewing level for clipping, distortion, dropouts, sync drift and loop seams. A file can look fine in a short local preview yet expose a problem only at its transition, so include the start and end of a loop in the test.
Keep the test channel or test window distinct from the intended public broadcast where practical. Check the encoder output and YouTube Live Control Room together: one can show that FFmpeg is sending data, while the other helps you see what YouTube is receiving and whether it reports a stream issue. Record the actual command, FFmpeg version, source characteristics and observations so that a later change can be compared with a known test.
If a church broadcast stops after several hours, the settings are only one possible part of the diagnosis. This walkthrough on a church YouTube live stream stopping after a few hours is relevant when you need to separate source, process and connection symptoms rather than changing bitrate at random.
Monitor stream health during a 24/7 run
A successful start proves only that the stream began. For an always-on channel, check that the source keeps supplying content, FFmpeg remains active, output continues at real time, and the connection stays healthy over the periods when you expect to leave it unattended. A looping file can stall, a capture source can disconnect, and a host can run out of resources; encoding flags alone do not restart a process or restore a failed network path.
Use YouTube’s stream-health feedback and review any messages in Live Control Room. Pay attention to repeated warnings and changes over time rather than treating a green indication at launch as a long-term guarantee. Pair that view with local evidence such as FFmpeg logs and a check that the intended picture and audio are still advancing. Avoid exposing the stream key when sharing logs for help.
Plan recovery separately from encoding. Decide who or what will notice a stopped process, how you will confirm the source has returned, and what should happen before reconnecting. FFmpeg options do not provide host restart, power backup or network failover by themselves. If you run FFmpeg on an Indian VPS and see repeated disconnections, this guide to an FFmpeg YouTube stream stopping on an Indian VPS may help organise the investigation; test any change rather than assuming the cause.
If the pain is keeping a computer and its process running through the night, StreamNeo removes that particular burden by taking an uploaded video and running it as a YouTube live stream while your computer is off. The remaining work still includes preparing the file and channel, checking the result and deciding what viewers should see over time; it does not remove the need to test the content or review stream health.
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 bitrate should FFmpeg use for 1080p YouTube Live?
For H.264 SDR, YouTube recommends 14 Mbps at 1080p30 and 17 Mbps at 1080p60. Use the rate that matches the chosen frame rate, and check the current official guidance before starting a broadcast.
Should I stream 1080p at 30 or 60 fps?
Match the source and the motion: 30 fps is suitable for many static or low-motion scenes, while genuine fast motion may benefit from 60 fps. Upsampling a 30 fps source does not add real motion detail, and 60 fps requires more encoding work and a higher recommended bitrate.
Do these FFmpeg settings make a stream reliable for 24/7 use?
No. They align the encoded contribution with YouTube’s recommendations, but they cannot ensure the source, host, process or upload connection remains available. Test representative content and monitor both FFmpeg and YouTube’s stream-health feedback.
Is -re needed for every FFmpeg stream?
No. It is useful for pacing a file as if it were being read in real time, but FFmpeg cautions against adding it blindly to live capture or network inputs. Choose input handling for the source you actually have and verify that it stays continuous.