Start with the stream you intend to send, not with a bitrate copied from another channel. YouTube’s live ingest recommendation depends on the codec, resolution and frame rate, so a 1080p30 H.264 stream and a 1080p60 H.264 stream use different recommended values.
For a 24/7 FFmpeg stream, select the matching row in YouTube’s live encoder table, configure FFmpeg to produce those same video properties, and then test the complete setup on the upload connection that will run it. The recommendation is a starting point, not a guarantee that your line will sustain the stream overnight.
Why the bitrate depends on the whole stream
Bitrate is the amount of encoded data sent to YouTube over time. A higher-resolution picture contains more pixels to describe, while a higher frame rate sends more pictures each second. The codec also changes how efficiently that picture information is represented.
That is why “the best YouTube bitrate” is not a single setting. It is shorthand for a particular combination of codec, resolution and frame rate. If you change one of those properties, check the live-ingest table again rather than keeping the old number by habit.
For example, 1080p30 and 1080p60 have the same frame dimensions, but the 60-frame version sends twice as many frames each second. YouTube’s H.264 recommendations reflect that difference. A devotional loop with a static image may look visually simple, but it still needs to be encoded and delivered according to the properties you selected.
The bitrate also belongs to the live stream rather than to a general video-upload guide. YouTube has separate advice for uploaded videos. Use the official YouTube live encoder settings and bitrate table for an ingest decision.
For a 24/7 channel, this distinction matters because the chosen value is sent continuously. A configuration that appears acceptable for a short test can expose a weak upload path, unstable encoder process or unsuitable source when it runs through the night.
Find the matching row in YouTube’s table
First decide which codec, output resolution and frame rate your FFmpeg process will actually send. Then find that exact combination in YouTube’s live table. Do not select a bitrate first and attempt to make the other settings fit afterwards.
For the H.264 examples covered here, the recommended values are:
| H.264 output | YouTube recommended bitrate | YouTube listed minimum where supplied |
|---|---|---|
| 720p30 | 8 Mbps | Not stated here |
| 720p60 | 8 Mbps | Not stated here |
| 1080p30 | 14 Mbps | 5 Mbps |
| 1080p60 | 17 Mbps | 6 Mbps |
These figures are from YouTube Help, with the publication year not shown on the retrieved page and accessed in 2026. They are recommendations for the listed live-ingest combinations, not a promise of picture quality or connection stability.
The table also has separate codec columns. For comparison, YouTube lists AV1 or H.265 at 10 Mbps for 1080p30 and 12 Mbps for 1080p60 in the cited table. Do not carry an H.264 value into an AV1 or H.265 configuration. Check the column for the codec your installed FFmpeg build is using.
The word “minimum” needs care as well. It is not a replacement for the recommended value, and it does not describe the capacity of your internet connection. It is a value shown in YouTube’s table for that particular combination. Your practical test still needs to use the configuration you intend to keep.
If you are unsure whether a stream should be 720p or 1080p, compare the source material and the upload path rather than assuming that the larger resolution is automatically the better choice. A fixed camera, prayer screen or low-motion ambience loop may not benefit from a resolution change in the same way as a local-news loop with readable text and frequent scene changes.
Three H.264 examples
720p30
For an H.264 stream at 1280 by 720 and 30 frames per second, YouTube’s recommended value is 8 Mbps. In FFmpeg, that means the video encoder should be configured for the 720p30 target and its bitrate setting should correspond to that recommendation.
This can suit a channel whose source is prepared at 720p, or a 24/7 station where the operator has decided that 720p is the appropriate output. It does not mean that every 720p source must be sent at 8 Mbps regardless of codec or frame rate. The row is specific to H.264 and the stated frame rate.
1080p30
For H.264 at 1920 by 1080 and 30 frames per second, YouTube recommends 14 Mbps and lists 5 Mbps as the minimum in the table. The recommended value is the one to use when your selected output is genuinely 1080p30 H.264 and the connection can sustain it.
A useful example is a study channel showing slides, a talking presenter and occasional screen changes. Set the encoder to output 1080p30, rather than leaving it at an automatic or inherited frame rate, and then test the result with those slides and transitions. If the source is only 720p, scaling it up does not create additional detail, although the output can still be deliberately configured as 1080p for other production reasons.
The separate article on YouTube Live settings for 1080p at 30fps can help you review the surrounding settings. Keep its scope separate from this decision: the bitrate still has to match the codec, resolution and frame rate you are using.
1080p60
For H.264 at 1920 by 1080 and 60 frames per second, YouTube recommends 17 Mbps and lists 6 Mbps as the minimum. This is not the same recommendation as 1080p30, even though the pixel dimensions are unchanged.
Use this row only when the encoder really sends 60 frames per second. Choosing 17 Mbps while the output is actually 30 frames per second does not turn it into a 60-frame stream. Conversely, setting 60 fps for a source that does not contain useful motion can increase the work and data sent without adding meaningful movement.
A music visualiser, sports-related loop or camera feed may make a higher frame rate useful, but make that decision from the source and viewing purpose. A mostly static bhajan card or a low-motion rain scene may have different requirements. The test should represent the content, not just a colour bar or a still frame.
Make the encoder match the row
The bitrate field is only one part of the FFmpeg command. Before starting the process, write down the intended codec, width, height and frame rate. Then confirm that the command produces those values rather than assuming that an input file’s properties will be preserved.
YouTube’s encoder guidance recommends constant bitrate, a two-second keyframe frequency and no more than four seconds between keyframes. It supports RTMP and RTMPS ingest, and recommends RTMPS for encrypted transport. Review the current YouTube live encoder guidance before finalising a production command.
In practical terms, an H.264 1080p30 target should have all of these elements aligned:
- H.264 video encoding.
- 1920 by 1080 output resolution.
- 30 frames per second.
- The 14 Mbps recommended video bitrate from YouTube’s H.264 row.
- Constant-bitrate behaviour and a two-second keyframe interval.
- An ingest URL and stream key obtained from the YouTube live setup.
For H.264 1080p60, change the frame-rate target and use the corresponding 17 Mbps recommendation. For 720p30, use the 720p dimensions, 30 frames per second and the 8 Mbps H.264 recommendation. The audio settings must also be tested as part of the complete stream, but they do not change which H.264 video row you select.
Do not paste a command from an unrelated machine and assume every option exists in your FFmpeg build. Encoder names, hardware support and muxer behaviour depend on the installed build and the available input. FFmpeg’s official protocol documentation covers RTMP-related output, while the command itself still needs to be adapted and tested for your source.
YouTube’s live configuration supplies the stream key and ingest details. Treat the key as a secret: do not put it in a public article, screenshot, shared script or support message. If you believe it has been exposed, use YouTube’s current stream-management controls to replace or reset it where available. The YouTube live stream settings guide explains the settings held in YouTube rather than in FFmpeg.
Check upload capacity and stream health
The recommended bitrate is a target for the outgoing video, not evidence that your internet connection can sustain it. Run the test from the same location and, as far as possible, on the same network path that will carry the 24/7 stream. A speed-test result taken on a different connection does not validate the production link.
Look beyond the headline upload number. Other devices may use the connection, the route to YouTube may behave differently at busy times, and a wireless link may vary during the day. The official guidance does not establish a universal headroom multiplier, so do not invent one and present it as a YouTube rule.
Start a private or otherwise controlled test broadcast using the intended codec, resolution, frame rate, bitrate and audio. Watch YouTube’s live preview and stream-health messages while the test runs. Also watch the FFmpeg output for encoding errors, dropped output, reconnect messages, increasing queues or a process exit.
For a 24/7 service, decide in advance what an operator will do when the health status changes. Record the normal startup check, the warning signs that need investigation and the point at which the stream should be restarted. If the process stops, an alert should identify that event, but an alert alone is not a recovery plan.
FFmpeg documents RTMP output and also documents the FIFO muxer, including recovery-related options. FIFO recovery can be one resilience mechanism, but it is not a guarantee of uninterrupted viewing, a YouTube reconnect guarantee or a universal ready-to-run command. Test the behaviour deliberately with your actual build and input.
A hosted workflow can remove the need to leave a personal computer running. For example, StreamNeo removes the specific burden of keeping your own machine switched on and restarting the uploaded stream when the connection process drops, while you still need to choose appropriate content, protect the stream key and check that YouTube is receiving the broadcast.
Test with representative audio and motion
A short test is useful only if it resembles the broadcast that viewers will receive. Include the real type of movement, text, transitions and audio. A static image can hide problems that appear when a ticker scrolls, a video scene changes or a visualiser moves across the frame.
For a devotional or instrumental channel, test a representative music segment, title card and transition. For a local-news loop, include the smallest text viewers must read and the scene changes used in the programme. For a study channel, include slides, cursor movement and any screen recording. For a fireplace or rain station, include the moving texture rather than testing only the still background; the fireplace and rain loop guide covers the content side of that kind of stream.
Listen to the audio on the YouTube preview, not only in the local source player. Check for silence, clipping, unexpected channel changes, drift or a mismatch between sound and picture. A clean video health message does not by itself confirm that the programme is pleasant to watch.
Also test the handover between loops or files. An FFmpeg process may continue running while the source has reached an unintended end, repeated a wrong segment or produced a gap. The exact command depends on how your input is prepared, so document the expected behaviour and confirm it in the preview.
Use the same output resolution and frame rate during the test as in production. Changing from 1080p30 during testing to 1080p60 after launch invalidates the bitrate comparison. The same applies to switching from H.264 to another codec without returning to the appropriate YouTube table row.
Adjust settings from evidence, not habit
After the test, separate problems by cause. If YouTube reports an unstable connection or the upload path cannot sustain the selected stream, first check whether the link is being shared, whether the output is sending the expected bitrate and whether the network route is stable. Do not immediately change several encoder settings at once.
If the link is stable but the image is unsuitable, inspect the source, scaling, frame rate and encoder workload. A higher bitrate cannot restore detail that was absent from a low-resolution source. A larger frame rate cannot create motion that the source never contained. Likewise, reducing the target resolution is a real change to the stream, not merely a cosmetic bitrate adjustment.
If you move from 1080p60 to 1080p30, select the 1080p30 row and retest. If you move from 1080p to 720p, select the matching 720p row and retest. If you change codec, return to the codec-specific column. Record each trial so that you know which combination produced each result.
Do not lower the bitrate while leaving the encoder’s stated target at 1080p60 and then describe the result as a tested 1080p60 configuration unless that exact combination has been tested. YouTube’s minimum and recommended figures are table entries, not permission to ignore the rest of the stream properties.
For a 24/7 deployment, keep a small operating record containing the chosen row, FFmpeg build, source files, output settings, test time, observed health messages and restart procedure. That record makes an overnight fault easier to diagnose, particularly when the person responding to it did not create the original command.
If you are deciding whether to run the process locally or elsewhere, compare the actual operational requirements rather than choosing only by bitrate. A local setup may depend on power, network and a machine that remains available. A hosted setup may change how you upload the source and monitor the process. The cloud-server guide for a 24/7 YouTube stream in India discusses that wider operating choice without changing the bitrate method described here.
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 a 1080p30 H.264 stream?
YouTube’s live table recommends 14 Mbps for H.264 at 1080p30 and lists 5 Mbps as the minimum for that row. Confirm that the encoder is actually producing 1080p30 H.264, then test the setting on the upload connection you will use.
Is 17 Mbps always right for 1080p60?
No. YouTube recommends 17 Mbps for H.264 at 1080p60, but that value applies to that exact codec, resolution and frame rate combination. It is not a universal answer for every 24/7 stream, and your upload connection still needs to be tested.
Can I use an H.264 bitrate for AV1 or H.265?
Do not assume that you can. YouTube lists codec-specific recommendations, including separate values for AV1 or H.265, so choose the row for the codec your FFmpeg build actually sends.
Does FFmpeg recovery guarantee an uninterrupted 24/7 stream?
No. FFmpeg’s documented output and FIFO recovery features can help a process respond to some interruptions, but they do not guarantee continuous YouTube playback or successful reconnection in every situation. Test the recovery behaviour and keep a monitoring and operator procedure for the live channel.