For H.264 YouTube Live, start with CBR encoding, the bitrate recommended for your chosen resolution and frame rate, and a keyframe every two seconds. For example, YouTube lists 10 Mbps for 1080p30, 17 Mbps for 1080p60, and 8 Mbps for both 720p30 and 720p60.
Those values describe the video sent to YouTube, not what every internet connection can sustain. A sound FFmpeg setup matches the resolution, frame rate and bitrate to your upload path, then proves the combination with a test stream before you depend on it overnight.
Choose an ingest resolution and frame rate
Resolution and frame rate are the first decisions because they determine the amount of picture data your encoder must prepare and the bitrate YouTube recommends for the live input. More pixels can make text, artwork and moving scenes clearer, while a higher frame rate can make movement look smoother. Neither is automatically the better choice for an always-on channel.
A devotional channel showing mostly still artwork may have little to gain from 60 frames per second. A local news loop with scrolling text, or a gaming channel with rapid movement, may benefit more from 60 fps if the source and connection can support it. A study stream with slides and a talking-head segment may be more practical at 1080p30 than at 1080p60.
Choose the output format rather than relying on whatever size the source happens to have. If your source is a 1080p video, sending it at 1440p does not create missing detail. It only asks the encoder and upload connection to carry a larger output. Likewise, reducing a 4K source to 1080p can be sensible when the channel needs a more forgiving upload requirement.
For a 24/7 channel, reliability matters over the whole run. YouTube’s live guidance recommends choosing a quality that works for the available connection and testing before the event. The table in the next section gives the published H.264 starting points, but it does not turn a weak or variable upload path into a reliable one.
If you are still deciding whether FFmpeg suits your workflow, the practical differences in OBS versus FFmpeg for looping videos are worth considering. FFmpeg is precise and easy to reproduce once the command is right, but it gives you fewer visual controls than a graphical application.
Use the matching YouTube H.264 bitrate
Use the H.264 live-ingest value for the exact resolution and frame rate you have selected. YouTube’s current live encoder guidance lists these recommended video bitrates:
| H.264 live input | YouTube recommended video bitrate |
|---|---|
| 720p30 | 8 Mbps |
| 720p60 | 8 Mbps |
| 1080p30 | 10 Mbps |
| 1080p60 | 17 Mbps |
| 1440p30 | 21 Mbps |
| 1440p60 | 34 Mbps |
| 2160p30 | 42 Mbps |
| 2160p60 | 50 Mbps |
These are ingest recommendations for the listed H.264 live inputs. They are not guarantees of picture quality, stream stability or available upload capacity, and they should not be applied indiscriminately to another codec, resolution, frame rate, encoder or upload route. The H.264 table is also separate from YouTube’s guidance for uploading finished video files. Do not use the upload table as a substitute for the live-encoder table.
For a straightforward starting point, 720p30 at 8 Mbps is less demanding than 1080p30 at 10 Mbps. That does not mean 720p will always look better or remain connected, but it gives the connection less video data to carry. At 1080p60, the listed recommendation rises to 17 Mbps because the output contains twice as many frames as 1080p30.
The 720p figures deserve attention because YouTube lists 8 Mbps for both 720p30 and 720p60. The frame rate still changes the FFmpeg keyframe setting, however. At 30 fps, a two-second interval is 60 frames. At 60 fps, it is 120 frames.
For higher resolutions, check whether the source actually benefits from the extra output size. A 1440p30 stream has a listed recommendation of 21 Mbps, while 2160p30 has 42 Mbps. Those values may be appropriate for a detailed source and a capable upload path, but a lower resolution that remains consistent can be the more useful choice for viewers.
YouTube’s official live encoder settings are the authority for the current table. Check that page again when you revisit a long-running setup, particularly if you are considering AV1 or H.265 rather than H.264. This article’s FFmpeg examples use H.264 and should not be read as codec-independent instructions.
Set CBR encoding
CBR means constant bitrate. In a practical YouTube FFmpeg command, the target video bitrate and the rate-control ceiling are set to the same value, so the encoder aims to deliver a predictable stream rather than changing its output substantially with each scene.
For 1080p30, the starting value is 10 Mbps. In FFmpeg syntax, that becomes -b:v 10M. Setting -maxrate 10M keeps the configured maximum at the same value in this example. A buffer setting such as -bufsize 20M gives the rate-control system room to manage short-term changes, but that particular buffer value is a command design choice, not a YouTube requirement.
The important distinction is between a target and a connection guarantee. CBR controls what FFmpeg tries to produce. It cannot increase the capacity of a congested broadband line, correct packet loss, or prevent another device from using the upload connection. If the line cannot carry the stream reliably, changing the command to CBR does not solve the underlying limitation.
The same principle applies to a 1080p60 stream. YouTube’s H.264 recommendation is 17 Mbps, so a corresponding starting point would use -b:v 17M and -maxrate 17M. For 720p30 and 720p60, use 8 Mbps, while calculating the keyframe distance separately from the bitrate.
Do not silently mix a bitrate from one row with the resolution and frame rate from another. A command labelled 1080p60 but configured with the 1080p30 value is not using the same published starting point. It may still be useful in a particular test, but you should describe it accurately and review the resulting stream health rather than assuming the table’s 1080p60 recommendation applies.
FFmpeg documents -b:v, -maxrate and -bufsize as video rate-control options. Its available options can vary with the installed build and encoder. The FFmpeg documentation is the right place to confirm the syntax supported by your local version, especially if you are using a packaged build on a small always-on computer.
Set a two-second keyframe interval
A keyframe is a complete reference picture. Other frames can describe changes relative to it, which reduces the amount of data needed, but a decoder needs suitable reference points to begin or recover playback. For a live service, regular keyframes also give the platform more frequent points at which it can work with the incoming stream.
YouTube recommends a two-second keyframe frequency and says not to exceed four seconds. In FFmpeg with libx264, the -g option sets the GOP interval in frames. To convert YouTube’s time-based recommendation into a frame count, multiply the encoded frame rate by two.
| Output frame rate | Two-second GOP value |
|---|---|
| 30 fps | -g 60 |
| 60 fps | -g 120 |
This conversion assumes the output really is being encoded at the stated frame rate. If the input is variable frame rate, or FFmpeg is producing a different output rate than you intended, a frame-count setting may not represent two seconds in the way you expect. Confirm the output frame rate rather than reading it only from the source filename or media player.
For 1080p30, use -g 60. For 1080p60, use -g 120. The same frame calculation applies to 720p30 and 720p60: use 60 for 30 fps and 120 for 60 fps. The bitrate changes with the table, but the two-second frame calculation follows the output frame rate.
YouTube’s maximum of four seconds is not a reason to choose a longer interval when two seconds is available. A longer GOP can reduce keyframe overhead in some encoding situations, but it also gives the live service fewer regular reference points. Start with two seconds, then investigate a different value only for a specific, tested reason.
Avoid adding -tune zerolatency automatically. It changes encoder behaviour and may conflict with the B-frame guidance YouTube lists for its live settings. If you have a particular latency requirement, treat it as a separate trade-off and verify the resulting stream rather than assuming the tune belongs in every 24/7 command.
Build and review the FFmpeg command
The following is a practical H.264 starting template for 1080p30. It translates the published bitrate and keyframe guidance into FFmpeg controls, but it has not been run or tested as part of this article. Replace the input and account-specific ingest details with your own values.
ffmpeg -re -i VIDEO_INPUT \\
-c:v libx264 -pix_fmt yuv420p \\
-b:v 10M -maxrate 10M -bufsize 20M -g 60 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv 'rtmps://YOUR_YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Here is what the important parts do:
-reasks FFmpeg to read the input at its native playback speed rather than sending a file as fast as the computer can process it. This is appropriate for a pre-recorded source being used as live input.-c:v libx264selects the H.264 encoder used in this example.-pix_fmt yuv420pselects a common pixel format for the output. Confirm the result with your build and the YouTube stream-health panel.-b:v 10Msets the 1080p30 video bitrate target.-maxrate 10Msets the example’s rate ceiling, while-bufsize 20Mis a rate-control choice rather than a value mandated by YouTube.-g 60requests a 60-frame GOP, which corresponds to two seconds at 30 fps.-c:a aac -b:a 128k -ar 44100encodes AAC stereo audio at the commonly used audio starting values listed in YouTube’s guidance. Make sure the input actually has suitable channels and sample-rate behaviour.-f flvselects the container used for the RTMP-family output.- The final URL contains the YouTube ingest address and your stream key.
Treat the stream key as a secret. Do not place it in a public script, screenshot, support post or shared document. If you think it has been exposed, use YouTube Live Control Room’s controls to manage or replace it according to the current account interface.
For 1080p60, change the video settings to -b:v 17M -maxrate 17M and use -g 120. For 720p30, use 8 Mbps and -g 60; for 720p60, use 8 Mbps and -g 120. Also make sure the actual output dimensions and frame rate match the label you are using. A bitrate value alone does not make a 720p or 1080p output.
YouTube’s advanced guidance also covers progressive scan, B-frames, reference frames, CABAC, square pixels, Rec. 709 for SDR and 8-bit SDR. It lists 44.1 kHz for stereo, 48 kHz for 5.1, and 128 Kbps stereo audio. These are additional settings to review, not a promise that one command will suit every source, encoder build or content type.
If your source is a looped file, inspect the file itself as well as the command. A black frame, audio pop or abrupt timestamp at the loop boundary can be visible even when bitrate and keyframes are correct. The guide to fixing loop seams, black frames and audio pops covers that separate part of the workflow.
Test the output and connection before going live
Run a private or otherwise controlled test with content that resembles the real channel. A still devotional image is not a useful test for a news loop with scrolling text. Include the movement, scene changes, audio and loop transitions that will occur during the overnight run.
Start by checking the local FFmpeg output. Look for encoder errors, repeated reconnect messages, dropped input, unexpected frame-rate changes and audio warnings. Then inspect YouTube’s stream-health panel for warnings or irregular incoming data. A command can be syntactically valid while the resulting stream still has a connection or source problem.
Test the connection at the time and location where the channel will normally operate. A speed-test result taken on another network, or during a quiet part of the day, does not establish what the upload path will do during the intended run. Leave enough headroom for normal network variation and other devices, rather than treating the published video bitrate as the full capacity your connection needs.
If the stream drops, do not immediately raise the bitrate. First compare the selected output with the connection, check whether another device is using upload capacity, and review the messages from both FFmpeg and YouTube. Reducing resolution or frame rate may be a more useful test than changing several encoder options at once.
A 24/7 channel also needs a recovery plan. Decide what should happen after a temporary outage, whether the source resumes at the expected point, and how you will notice a failed process when nobody is watching. The article on reconnecting a podcast stream after an internet outage is relevant if your channel depends on a local encoder and a long-running connection.
For a pre-recorded channel, removing the home computer from the critical path can also be worth considering. A cloud-based workflow can keep the uploaded file and YouTube connection running while your computer is switched off; StreamNeo is designed for that specific hand-off, with the stream key entered once and automatic monitoring and restarting when the broadcast drops. It is YouTube-only, so it is not a general solution for a output.
Do not treat a successful short test as proof of uninterrupted operation. It shows that the selected input, command and connection worked during that test. Continue to check stream health after going live, and keep a known-good lower-demand configuration available if the chosen output proves too demanding.
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 in FFmpeg?
For H.264 live input, YouTube lists 10 Mbps for 1080p30 and 17 Mbps for 1080p60. Use the value as an ingest starting point, then test whether your encoder and upload connection can sustain it reliably.
What should -g be for a two-second keyframe interval?
At 30 fps, use -g 60; at 60 fps, use -g 120. These values convert two seconds into frames, so confirm that FFmpeg is producing the frame rate you intended.
Does CBR guarantee a stable YouTube stream?
No. CBR controls the encoder’s rate target and ceiling, but it cannot fix an upload connection that is congested, lossy or too limited for the selected output. Test with representative content and review YouTube’s stream-health messages.
Should I use RTMP or RTMPS?
Use RTMPS when it is available in the ingest details supplied by YouTube. It is the encrypted extension of RTMP; YouTube’s current guidance recommends it for live transmission. Confirm the exact URL shown in YouTube Live Control Room rather than copying an address from an old command.