For an always-on YouTube stream, choose the ingest resolution and frame rate first, then use the matching H.264 bitrate recommendation in YouTube’s current encoder guidance. In FFmpeg, configure constant bitrate behaviour and set a two-second keyframe interval; YouTube advises not to exceed four seconds.
Those settings are a starting point, not a promise that a stream will remain online. The source, sustained upload capacity, encoder build, network and process supervision all matter. The steps below show how to make the encoder settings agree with the chosen output and what to check before leaving a channel running overnight.
Choose resolution and frame rate first
Resolution and frame rate determine which row of YouTube’s bitrate guidance applies. Decide what the content needs and what your connection can sustain before entering a bitrate. A static devotional image with audio may not need the same output as a local news loop with moving footage, but you should still select a deliberate output format and use the recommendation for that exact format.
Frame rate is important even when the source looks simple. A 1080p30 stream and a 1080p60 stream are not interchangeable settings: they use different bitrate recommendations and need different GOP sizes to make a two-second keyframe interval. If the source is 30 fps, sending it at 60 fps does not create extra original motion; it may increase encoding and network demands without improving the material.
Choose a quality that your upload connection can support continuously, not just in a brief speed test. Other devices sharing a connection, changes in wireless conditions and upstream congestion can affect the available capacity. Leave room for audio and protocol overhead rather than assuming every bit of a measured upload rate can be used for video.
If the connection cannot reliably sustain the recommendation for your preferred format, consider a lower resolution or frame rate and use that row’s recommendation. Do not silently lower the video bitrate while presenting the output as equivalent to YouTube’s recommended setting. For a radio-style channel, the visual may be a still or a modest loop, but the encoder still needs stable timing and a network path that can carry the output.
The decision also affects viewing. YouTube transcodes live streams into viewer renditions, so the bitrate you send is the ingest signal, not a direct promise about what every viewer receives. Keep your own source and output choices clear when troubleshooting: the source file’s properties do not necessarily describe the stream being sent.
Find YouTube’s current H.264 bitrate recommendation
Use YouTube Help’s current encoder settings and bitrate table and select the H.264 row matching the output resolution and frame rate. The table below reproduces the H.264 recommendations supplied in the research notes. Recommendations can be revised, so verify the live English-language page when configuring a new stream rather than treating these values as timeless.
| Ingest resolution and frame rate | YouTube H.264 recommended video bitrate |
|---|---|
| 360p30 | 4 Mbps |
| 480p30 | 4 Mbps |
| 720p30 | 8 Mbps |
| 720p60 | 8 Mbps |
| 1080p30 | 14 Mbps |
| 1080p60 | 17 Mbps |
| 1440p30 | 21 Mbps |
| 1440p60 | 34 Mbps |
| 2160p30 | 42 Mbps |
| 2160p60 | 50 Mbps |
These are YouTube’s technical recommendations for H.264 ingest, not independent measurements or guarantees of picture quality. Notice that 1080p60 has a different recommendation from 1080p30. Do not copy a bitrate from one row simply because both outputs are described as 1080p.
Codec matters too. The figures above are for H.264, which is the codec used by the libx264 example below. YouTube’s table gives different recommendations for other codecs; do not combine those values with an H.264 command. If you select another encoder, return to the official table and read the recommendation for that codec, resolution and frame rate.
The video bitrate is not your entire network requirement. Audio, transport overhead and fluctuations add to the data being sent, and the connection must carry the stream continuously. If the chosen row is beyond the capacity you can depend on, choose a lower output format or improve the connection before relying on it. A lower target can be a practical compromise, but it is a different choice from following the listed recommendation.
Set CBR and the selected video bitrate in FFmpeg
FFmpeg’s -b:v sets a target video bitrate; by itself it does not mean the encoder is operating in constant bitrate mode. FFmpeg’s documentation describes variable bitrate as the default behaviour and explains rate-control options such as -minrate, -maxrate and -bufsize. YouTube recommends CBR for live encoder settings, so configure and check the behaviour of the encoder you are actually using.
For a typical FFmpeg H.264 setup, matching -b:v, -minrate and -maxrate is a common way to request CBR behaviour. The buffer size is also part of rate control. It is not a universal YouTube-mandated number: use a value appropriate to your encoder and test what it produces. The example uses a buffer setting as an illustration, not as an official ingest requirement.
Here is a starting command for a file input sent as 1080p30 H.264. The bitrate matches the supplied current YouTube recommendation for that row. Replace INPUT, adapt mapping and filters to the actual media, and substitute the RTMPS ingest URL and stream key obtained in Live Control Room. Do not copy a real stream key into a public script or log.
ffmpeg -re -i INPUT \\
-c:v libx264 -preset veryfast -tune zerolatency \\
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \\
-b:v 14M -minrate 14M -maxrate 14M -bufsize 28M \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://YOUTUBE_INGEST_URL/STREAM_KEY'
14M expresses a target of 14 megabits per second using FFmpeg’s scale suffix. The example’s -bufsize 28M is illustrative; it is not identified by YouTube as a requirement. -preset veryfast is a possible x264 speed-versus-compression choice, and -tune zerolatency changes encoder behaviour; neither is a substitute for testing the output. Exact options and results depend on the FFmpeg build and encoder.
The command uses -re because the input is a file and should be read in real time for this kind of paced file playback. It is not a universal addition for every capture input; capture devices and other live inputs have their own timing. Check that libx264 is present in the installed FFmpeg build. FFmpeg documents that support for this encoder depends on a build configured with the libx264 libraries.
For 1080p60, the supplied current table’s H.264 recommendation is 17 Mbps, and the two-second GOP uses 120 frames at 60 fps. Update the frame-rate and GOP options along with the bitrate; do not change only -b:v. You can read about a broader operational setup in this guide to streaming a radio station from a VPS, but choose FFmpeg values from YouTube’s current guidance for your own output.
YouTube recommends RTMPS as the secure ingest protocol. Obtain the ingest URL and key from the channel’s Live Control Room settings, and treat the key as a password: avoid putting it in screenshots, shared command histories or public repositories. YouTube’s live stream settings help describes stream configuration. If the key is exposed, use the channel’s official controls to replace it and update the encoder.
Set a two-second keyframe interval
A keyframe, or I-frame, gives a decoder a reference point from which to begin displaying video. YouTube’s current guidance recommends a keyframe frequency of two seconds and says not to exceed four seconds. Two seconds is a practical target, not the only technically acceptable value; the important boundary in the guidance is that the interval must not be longer than four seconds.
FFmpeg’s -g controls the maximum GOP size in frames. To express a two-second interval, multiply the output frame rate by two: at 30 fps, use -g 60; at 60 fps, use -g 120. A GOP measured in frames only represents two seconds if the actual output rate is the one you intended. If you change -r, recalculate the GOP rather than retaining the old number.
For libx264, -keyint_min controls the minimum keyframe interval. FFmpeg’s documentation notes that the minimum is ignored unless it equals the GOP size; setting it equal to -g is useful when you want a fixed cadence. In the 30 fps example, both are 60; at 60 fps, both are 120. -sc_threshold 0 disables x264 scene-change keyframe decisions, a common way to avoid scene cuts adding keyframes off the planned cadence. These options are encoder-specific in effect, so confirm behaviour for your chosen encoder.
| Output frame rate | Frames in two seconds | Example GOP options |
|---|---|---|
| 30 fps | 60 | -g 60 -keyint_min 60 |
| 60 fps | 120 | -g 120 -keyint_min 120 |
Do not set -g 2 to mean two seconds. That would mean a GOP of two frames, not a two-second duration. Similarly, do not treat -g 60 as universally two seconds: it is two seconds at 30 fps, but only one second at 60 fps. The interval is a relationship between the frame count and the output frame rate.
If you alter frame rate during troubleshooting, revisit the GOP as well. YouTube’s error guidance calls out keyframe cadence when changing frame rate. The useful check is not merely that an option appears in the command, but that the encoded output is using the expected frame rate and keyframe pattern.
Check audio and encoder output
A stream can have correct video settings and still be unpleasant or unusable if the audio is missing, clipped or out of sync. YouTube lists AAC and MP3 as supported ingest audio codecs. The example uses AAC stereo at 128 kbps and a 44.1 kHz sample rate as a reasonable starting point drawn from YouTube’s advanced recommendations, not as a requirement for every channel.
Check the actual source before assuming the example’s audio options fit. Confirm that an audio stream exists and that FFmpeg maps the intended track. A file with multiple language tracks or a capture setup with separate audio input may need explicit mapping. Listen to a representative passage at the beginning and after any loop point; a devotional recording that becomes silent at a file boundary will not be fixed by changing the video bitrate.
Inspect FFmpeg’s output while starting the stream. Look for whether the selected encoder opened successfully, whether the intended output frame rate and video size are reported, whether audio is being encoded, and whether connection errors repeat. libx264 may not exist in every build; if FFmpeg reports an unknown encoder, verify the installed build and its enabled encoders rather than repeatedly editing unrelated bitrate flags.
Test with representative content, not only a still frame or a short quiet section. Include the busiest motion your loop contains and its normal audio level. Watch for dropped frames, warnings, unexpected reconnects and changes in output. A file-based always-on channel also needs a plan for what happens at the end of the input: an encoder command that reaches end-of-file does not, by itself, make the file repeat forever.
Settings and process reliability are separate concerns. An always-on stream needs an available input, a process that is restarted or reconnected appropriately after failures, logs that someone can inspect and a way to notice a problem. YouTube’s encoder guidance does not prescribe one universal FFmpeg restart policy. If a broadcast repeatedly drops, use a diagnostic path such as troubleshooting a YouTube live stream that goes offline rather than assuming the bitrate is the only cause.
Verify stream health in Live Control Room
Start a private or otherwise suitable test before depending on the configuration. YouTube recommends testing with representative audio and motion and monitoring stream health and messages during the event. In Live Control Room, confirm that the incoming stream appears with the expected resolution and frame rate, and read any warnings rather than judging only by the preview image.
A preview that appears can still conceal a mismatch or an unstable connection. Check the stream health messages, then compare them with FFmpeg’s own output and the settings you selected. If YouTube reports an ingest problem, distinguish among an unsupported or incorrect output, a bitrate or connection issue, a key or URL problem, and the input itself. Change one relevant factor at a time and test again, so the result tells you something.
Do not confuse ingest bitrate with the available viewer qualities. YouTube processes the incoming feed into viewing renditions, and the viewer’s playback options can differ from the signal you send. When checking the encoder, focus on what is leaving FFmpeg and what Live Control Room reports as received, not solely on a rendition selected in the player.
For a 24/7 channel, the first successful test is not the end of the check. Confirm that the source remains available through its expected repeat or schedule, that audio continues, and that logs and alerts make an interruption visible. Keep the key private and document how to rotate it. A useful handover note records the chosen resolution, frame rate, codec, target bitrate, GOP settings, ingest endpoint location and the person who can respond to a failure.
If you want a no-PC approach for a prerecorded channel, this article on checking a prerecorded YouTube stream without keeping a PC on explains the operational distinction. StreamNeo removes the need to keep your own computer running for an uploaded file broadcast, which addresses the specific problem of a home machine needing to stay on; it does not change the need to choose suitable encoding settings or check the channel in Live Control Room.
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 I use for 1080p YouTube Live?
Choose the row for the codec and frame rate you are sending. In the current H.264 figures reproduced above, 1080p30 is 14 Mbps and 1080p60 is 17 Mbps; check YouTube Help’s live encoder table again when you configure the stream because recommendations can change. If your sustained upload cannot carry the selected format reliably, step down to a lower resolution or frame rate and use its matching recommendation.
How do I set a two-second keyframe interval in FFmpeg?
Set the GOP size to twice the output frame rate: -g 60 at 30 fps or -g 120 at 60 fps. With libx264, setting -keyint_min to the same value and using -sc_threshold 0 can help keep a regular cadence. Check that the actual output frame rate matches the calculation.
Is two seconds the only acceptable keyframe interval?
No. YouTube recommends two seconds and says not to exceed four seconds. Two seconds is a straightforward target for a regular live stream, but do not describe it as the sole acceptable setting.
Does -b:v alone make FFmpeg use CBR?
No. -b:v sets a target, while FFmpeg’s default rate-control behaviour can be variable. For a CBR request, configure the encoder’s rate-control options appropriately, such as matching target, minimum and maximum rates where supported, then test the output and monitor YouTube’s stream health.