For a 720p gaming VOD rerun on YouTube Live, use YouTube’s live-ingest guidance, not the bitrate table for uploading a finished video. Its recommended 720p rate is 6 Mbps for AV1 or H.265/HEVC and 8 Mbps for H.264, with the same figures listed for 30 and 60 fps.
Those are recommendations, not mandatory minimums or a guarantee that your connection can sustain them. On a slow upload, first choose a rate your connection can hold consistently, leave room for network variation and other traffic, then test the actual gameplay and audio before making the rerun public.
Choose 720p and a frame rate your connection can carry
A 720p picture can be sent at 30 or 60 frames per second. The higher frame rate shows more intermediate motion and can make fast gameplay easier to follow, but it also adds work for the encoder and may make a marginal setup less forgiving. A 30 fps stream is a sensible first test when upload capacity is limited; it is not a promise that the stream will be stable simply because the frame rate is lower.
YouTube’s live bitrate table happens to list the same recommended rate for 720p30 and 720p60. That does not mean every game looks equally good at either setting, or that a high-motion game will behave like a mostly static scene. Use the table as a starting point for encoder output, then judge the result with representative movement on screen.
Think of the connection as a sustained path, not a single speed-test result. Upload capacity can vary through the day, and the stream shares it with other household or office activity. If someone begins a large upload while the rerun is live, the available room for your broadcast may shrink even though the encoder settings have not changed.
Before changing anything, confirm that the speed test you are looking at measures upload. A high download result says little about the outbound capacity used to send a live broadcast. YouTube also advises testing the stream and checking its health rather than assuming a rate from the nominal package speed will work.
If the VOD is being looped from a local encoder, keep the workflow and bitrate question separate: the video file is the source, while the encoder sends a live signal to YouTube. For context on replaying a file as a live broadcast, see this guide to looping prerecorded videos on YouTube Live from Linux. A loop that plays smoothly on your computer can still encounter upload or encoding problems once it is sent live.
YouTube Live ingest bitrate guidance by codec
The figures below are YouTube’s live-ingest recommendations for 720p. They apply to both frame rates shown; the table does not prescribe a higher recommended bitrate for 60 fps than for 30 fps.
| Live output | Codec | Listed minimum | Recommended bitrate |
|---|---|---|---|
| 720p30 | AV1 or H.265/HEVC | 2 Mbps | 6 Mbps |
| 720p60 | AV1 or H.265/HEVC | 2 Mbps | 6 Mbps |
| 720p30 | H.264 | 3 Mbps | 8 Mbps |
| 720p60 | H.264 | 3 Mbps | 8 Mbps |
These values come from YouTube Help’s live encoder settings and bitrate table. Check YouTube’s current guidance and the options your encoder actually supports before setting up the stream. The codec column matters: for the same listed resolution and frame rate, YouTube’s table gives AV1 and H.265 a lower recommended rate than H.264. That is a table comparison, not a claim that the codecs deliver identical perceived quality at a particular bitrate.
Do not select AV1 or H.265 just because the number looks easier to fit into a slow connection. Your encoder must support the codec and be configured to send it correctly to YouTube. If it does not, H.264 is a straightforward choice, and you can reduce the stream’s demand in other ways if the recommended rate is beyond your stable capacity.
YouTube also lists RTMP or RTMPS as ingest protocols, recommends constant bitrate (CBR), and recommends a two-second keyframe interval, with a keyframe interval not exceeding four seconds. Those are separate encoder settings from the bitrate itself. Where the encoder exposes them, use YouTube’s published guidance and confirm the stream health after the test rather than relying on a setting label alone.
A prerecorded gaming VOD does not change the ingest table. While it is being broadcast as a live stream, the encoder still sends a live signal to YouTube. The later archived video is a viewing asset created from that broadcast, not the same workflow as uploading a finished file directly.
Minimum is not the same as recommended
YouTube’s table includes both a minimum and a recommended rate. At 720p, the listed minimum is 2 Mbps for AV1 or H.265 and 3 Mbps for H.264; the corresponding recommendations are 6 Mbps and 8 Mbps. The minimum column should not be read as YouTube promising that every game will look good at that rate or that every connection can hold it.
If your upload only has room for a rate near the listed minimum, treat that as a constrained test case. Rapid camera pans, detailed scenes, particle effects and simultaneous audio can expose visible softness or instability that a quiet menu screen does not. A static scene passing a test is not evidence that a busy match will look the same.
The practical question is not simply, “What bitrate should I use for a 720p stream?” It is, “What live bitrate can this connection sustain with enough spare capacity, and does the result remain acceptable during the busiest part of this VOD?” Start with codec support and available upload capacity, then test. If you cannot sustain a suitable rate reliably, reduce the demand rather than treating the minimum as a safe target.
Keep live ingest figures separate from YouTube’s upload recommendations. For an uploaded 720p finished video, YouTube lists 5 Mbps for standard frame rates (24, 25 or 30 fps) and 7.5 Mbps for high frame rates (48, 50 or 60 fps) in its recommended upload encoding settings. Those file-upload figures are not substitutes for live ingest settings during a VOD rerun.
Leave upload headroom on a variable connection
YouTube’s streaming tips say the total stream bitrate should not exceed available upload bandwidth and recommend leaving 20% room. Treat this as operating headroom, not spare capacity that should be filled by another background task. If your connection varies, headroom gives some room for ordinary fluctuation, but it cannot make an inadequate or unreliable upload suitable by itself.
For a simple planning calculation, divide the intended total stream bitrate by 0.8. A 3 Mbps stream divided by 0.8 calls for about 3.75 Mbps of available upload capacity before allowing for other network use. This is a calculation derived from YouTube’s 20% headroom advice, not a separate YouTube-published capacity threshold.
The word “total” matters. If you configure a primary and backup stream, YouTube says their bitrates and the headroom must fit the outbound connection. Other traffic on the same internet connection also competes for capacity. A speed test taken while the network is idle may therefore overstate what is available during the hours your channel is actually running.
For example, if a stable upload reading is 5 Mbps, it would be unwise to choose a stream rate that consumes almost all 5 Mbps. Use the headroom calculation, account for other users and traffic, and then test at a lower rate if needed. The example does not establish that any particular rate will work on your connection; local variation and the actual content remain relevant.
You can make a test more representative by checking upload at the time the channel normally runs and by avoiding large concurrent uploads during the test. If the result is inconsistent, plan for the weaker conditions rather than the best reading. A link to this 24/7 YouTube stream setup with OBS may help you review a local encoder workflow, but the connection still needs to be tested where it will be used.
Reduce frame rate or resolution if needed
When the chosen bitrate repeatedly produces a poor or unstable stream, reduce the amount of work the connection and encoder must carry. For a slow upload, 720p30 is a useful first comparison against 720p60 because it presents less frequent motion updates. YouTube lists the same bitrate guidance for the two frame rates, so changing to 30 fps does not automatically change the table’s recommended bitrate. It is a practical way to test whether motion and encoding demands are more manageable, not a guarantee of success.
If 720p30 still cannot be sent consistently at a rate that gives an acceptable result, consider a lower resolution. A smaller frame can reduce the amount of visual detail that needs to be carried, though the result may be less clear on larger displays. Choose based on the content: game text and interface elements may need more clarity than a wide, slow-moving scene.
Change one setting at a time where possible. If you lower both resolution and frame rate and then adjust bitrate, it becomes harder to tell which change helped. Compare short private or unlisted tests, note the encoder output and YouTube stream-health feedback, and view the result on a separate device if available.
Check the encoder’s actual output settings, not only a preset name such as “720p”. Presets may bundle resolution, frame rate, codec and bitrate together, and the precise choices vary by encoder. YouTube’s encoder setup guidance explains the general process for connecting an encoder; consult the current interface for the specific options available to you.
A 24/7 channel has a different trade-off from a short broadcast. A slightly less demanding picture that remains steady may be more useful than a sharper configuration that drops or needs repeated intervention. For a prerecorded video, the source remains the same, but the outgoing live signal still has to make the full trip to YouTube continuously.
Test the motion, audio and long-run workflow
Test with a segment that resembles the most demanding part of the VOD, not only its title screen. Include quick camera turns, moving backgrounds, busy combat or other fast changes likely to appear in the game. A calm opening may hide compression artefacts or dropped frames that become obvious during a match.
Include the actual audio mix. Game sound, voice-over, music and alerts can differ from a silent video test, and the stream should be judged as viewers will receive it. Confirm that speech is understandable where present and that the audio stays in sync with the picture. If the VOD contains material you do not control, check YouTube’s current copyright guidance before broadcasting it; a technical bitrate test does not answer rights questions.
Run a private or unlisted test where appropriate, then inspect YouTube’s stream health while the test is running and review playback afterwards. Look for recurring interruptions, buffering, soft detail in motion, audio problems and encoder warnings. A test is evidence about the conditions at that time, not a promise that a 24/7 broadcast will never encounter a later network change.
For a long rerun, decide what you need to preserve independently of the YouTube archive. YouTube’s archive guidance says streams shorter than 12 hours can be automatically archived, while streams exceeding 12 hours may not be captured, and recommends keeping a local archive backup. If the original VOD matters, keep a reliable copy rather than relying on the live archive as your only record.
For an always-on loop, the repeated source file also needs to be prepared for the duration and format of the broadcast. This guide to using FFmpeg to loop lofi tracks in a YouTube Live stream discusses a different kind of source material, but the general distinction is useful: playback preparation and live delivery are separate jobs. A smooth local loop does not prove the internet connection can carry the broadcast.
If monitoring and restarting a local machine through the night is the specific pain, StreamNeo can take that computer-off obligation out of a file-based YouTube rerun; it does not change the bitrate YouTube receives or remove the need to prepare and test the stream. Keep the bitrate choice grounded in the actual connection and the stream-health result, regardless of how the file is played out.
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 720p stream?
For YouTube Live, the table recommends 6 Mbps for AV1 or H.265/HEVC and 8 Mbps for H.264 at both 30 and 60 fps. It lists lower minimums, but you should choose according to what your upload can sustain with headroom and what your test looks like.
Can I rerun a VOD at 720p with limited upload speed?
Yes, if the connection can sustain the outgoing live stream at the settings you choose. Test with representative gameplay and audio, monitor stream health, and reduce frame rate or resolution if the upload is not stable enough.
Are YouTube upload bitrates the same as live-stream bitrates?
No. A finished 720p file upload has a separate set of encoding recommendations, while a VOD sent out as a live broadcast uses live-ingest guidance during the stream. Do not choose a live bitrate by copying the finished-file upload table.
Is 2 Mbps enough for 720p gaming?
YouTube lists 2 Mbps as the minimum for AV1 or H.265 at 720p and 3 Mbps for H.264, but a listed minimum is not a promise of acceptable quality for every game or network. Test the actual content and connection, and consider lowering the frame rate or resolution if motion or stability suffers.