If you are sending prerecorded footage to YouTube as a live event, use YouTube’s live-encoder settings, not its ordinary video-upload bitrates. For 720p, the live table recommends 8 Mbps for H.264 or 6 Mbps for AV1 and H.265, at both 30 and 60 fps; those targets do not guarantee a stable stream.
If you mean uploading a video file through YouTube Studio, that is a different workflow with different guidance. This distinction matters whether you are planning a devotional loop, study channel, ambience station or a local information feed that is meant to stay live.
Confirm which workflow you are using
“Pre-recorded video” can describe two different things. You might upload a finished file through YouTube Studio and publish it as a normal video, or send footage that was recorded earlier through an encoder as a live broadcast. Only the second case uses the live-ingestion figures in this article.
For a livestream, YouTube receives an ongoing encoded feed. It does not matter that the pictures were recorded yesterday rather than captured by a camera in real time: while the feed is being sent as a live event, the encoder’s incoming resolution, frame rate and codec determine which live settings are relevant. YouTube then processes the live feed for playback formats. You do not need to encode a separate copy at every viewer resolution.
For an ordinary upload, the file is transferred and processed as a video, rather than being sent as a continuous live feed. The upload recommendations are addressed separately below. If you are still deciding how to create a live event and connect an encoder, YouTube’s live-streaming setup guidance covers the platform workflow. A broader step-by-step guide to live streaming on YouTube may help put that setup in context.
Before changing a bitrate, settle this question first: will the audience encounter the video as a livestream, or as a regular upload? Applying upload figures to a live encoder can leave you below YouTube’s listed live target; applying live figures to an upload is not what the upload recommendations are for.
Choose 720p30 or 720p60 to match the footage
The choice between 30 and 60 frames per second should reflect the source material and the presentation you want to preserve. If the footage was recorded at 30 fps, sending it at 60 fps does not create extra recorded motion. If it was recorded at 60 fps and smooth movement matters, 60 fps may be the appropriate live input. Do not assume that a higher frame rate improves every loop; it depends on the actual material.
YouTube’s live bitrate table lists the same recommended bitrate for 720p30 and 720p60 in each codec family. That is a platform recommendation for these settings, not a claim that the two inputs look or behave identically. Frame rate affects how the footage is represented, while the listed bitrate target remains the same for the corresponding codec and 720p input.
For example, a 720p devotional video with slow camera movement and a 30 fps source can normally be configured as 720p30 rather than converted to 60 fps without a reason. A study channel showing slides may also have little visible motion, but the correct choice still starts with the source and the intended output, not a rule that static material always needs a particular frame rate. If you are looping scenes, the OBS transition settings guide is relevant to scene changes, but it does not replace YouTube’s live bitrate table.
If your source is 720p30, use the 30 fps row below; if it is 720p60, use the 60 fps row. Both rows have the same values, so you do not need to raise the listed bitrate solely because you selected 60 fps. These recommendations are specific to the 720p cases and codecs shown here; do not carry them across to other resolutions or codecs without checking YouTube’s current guidance.
Set live bitrate for the selected codec
YouTube’s live-ingestion table gives a minimum and a recommended bitrate for the 720p input. Treat the recommended value as the target to configure when your upload connection can sustain it. The minimum is a listed lower boundary, not a promise of acceptable picture quality or uninterrupted delivery.
| 720p live input | YouTube-listed minimum | YouTube-recommended bitrate |
|---|---|---|
| 30 fps, AV1 or H.265/HEVC | 2 Mbps | 6 Mbps |
| 60 fps, AV1 or H.265/HEVC | 2 Mbps | 6 Mbps |
| 30 fps, H.264 | 3 Mbps | 8 Mbps |
| 60 fps, H.264 | 3 Mbps | 8 Mbps |
The table reflects YouTube’s live-encoder recommendations for these specific combinations. H.264’s recommended value is higher than the AV1 or H.265 recommendation shown for 720p; if your encoder and workflow use H.264, do not substitute the lower figure simply because another codec has that recommendation. Likewise, a minimum should not be read as the best setting to choose when the connection can reliably carry the recommended target.
Set the bitrate in the encoder that is producing the incoming live feed. YouTube recommends constant bitrate (CBR) encoding for live video, with a keyframe interval of two seconds and no more than four seconds. Its live encoder page lists H.264, H.265 (HEVC) and AV1; codec availability depends on your encoder and workflow, so select a codec you can actually send and configure correctly. See YouTube’s live encoder settings for the current table and related parameters.
A selected bitrate is a sending rate, not a measurement of the quality of your internet connection. The available upload capacity must have room for the video feed and other network traffic. If several devices are uploading through the same connection, or the connection varies over time, the encoder may struggle even when its configured number matches the recommendation. YouTube’s table sets a target; it does not certify that a particular connection will hold it overnight.
Keep ordinary upload guidance separate
For an ordinary 720p video upload, YouTube gives separate encoding recommendations: 5 Mbps for standard frame rates of 24, 25 or 30 fps, and 7.5 Mbps for high frame rates of 48, 50 or 60 fps. Those are file-upload recommendations, not live-ingestion targets. The official video upload encoding settings page also discusses upload formats and encoding.
The difference is practical. If a prerecorded file is being pushed as a livestream, use the live table above even though the pictures were recorded in advance. If you are uploading the file as a normal video, use the upload page’s recommendations instead. Do not choose 5 Mbps for a 720p30 live stream on the assumption that the upload row also applies to a live encoder; for H.264, YouTube’s listed live recommendation is 8 Mbps.
The upload guidance also recommends keeping the upload frame rate the same as the frame rate at which the footage was recorded. That advice belongs to the file-upload workflow. For a live feed, choose an input frame rate that reflects the source and your live configuration, then follow the live settings for that input. It is useful to keep a small note beside your encoder configuration stating whether the figures you are using came from the live or upload table, especially when the same file is used in both ways.
This distinction is useful for a channel that publishes highlights as uploads but also runs a continuous live loop. The file upload and the live playout are separate outputs, and each needs its own settings. If your channel runs lessons around the clock, the computer science lessons stream setup provides a more specific always-on context, but does not change the bitrate distinction.
Configure resolution, frame rate and the rest of the feed
Use 1280 × 720 as the 720p frame size, then set the frame rate to 30 or 60 fps according to the source and the live presentation. YouTube says it can detect resolution and frame rate automatically by default. If you need to select a resolution manually in Live Control Room, YouTube’s guidance calls for creating a custom stream key and enabling manual settings for stream resolution. Avoid forcing a manual value casually: a mismatch between what the encoder sends and what the event expects can complicate diagnosis.
For live video, configure CBR and a two-second keyframe interval, keeping the interval at or below four seconds. YouTube recommends RTMPS, its secure extension to RTMP. These are settings to check in the encoder or playout tool; they do not alter the bitrate target in the table. If your tool exposes more advanced controls, compare them against YouTube’s current encoder guidance rather than guessing at a value.
Audio is part of the test too. YouTube’s live settings list AAC or MP3, with 5.1 audio over RTMP/RTMPS supported only with AAC. For a straightforward stereo music, talk or ambience stream, check that the audio is present and remains in sync with the picture. A technically correct video bitrate does not solve an audio file that drops out, clips, or ends before the video loop does.
Think of the input as a complete feed: resolution, frame rate, video codec, bitrate, keyframes and audio all need to be coherent. If you are maintaining a long-running audio-led channel, the advice on keeping audio playing on a 24/7 stream addresses a separate but closely related failure mode. Do not change several encoder controls at once unless you have a reason; otherwise, if the picture or sound changes, you will not know which adjustment mattered.
Test the connection and watch stream health
YouTube recommends testing before starting a live stream. Do that with a representative section of the actual material: include the kind of movement, scene changes and audio the audience will hear. A still title card is not a useful test for a channel whose normal footage contains moving images, and a silent check will not reveal an audio problem.
Run the test through the same encoder, network connection and intended settings that you plan to use. Check that the event receives the intended resolution and frame rate, that audio is present, and that the stream-health display does not show an unresolved warning. Read the messages rather than relying only on whether a preview appears. The YouTube encoder setup information describes connecting an encoder; the live settings page explains the encoding recommendations.
A short test is a check of the setup at that moment, not proof that the connection will remain steady through a long broadcast. For a 24/7 channel, also consider what happens when the router restarts, the power drops or the playback process stops. Those operational risks are separate from the codec target. A useful comparison of VPS and cloud streaming approaches can help you think through where playout runs and what you must monitor, without changing YouTube’s ingestion requirements.
During a live event, keep an eye on YouTube’s stream-health messages and the encoder’s own output status. If YouTube reports a problem, note when it begins and what the encoder is sending at that point. That gives you a more useful starting point than repeatedly changing bitrate based only on a viewer saying the picture looked soft.
Adjust according to what you observe
Start with the recommended bitrate for the actual codec and 720p frame rate, then observe the feed under representative conditions. If the encoder reports dropped frames or YouTube reports a connection or ingestion issue, check whether the upload connection has enough available capacity and whether other traffic is competing with the stream. Also confirm that the encoder is not attempting a different resolution, frame rate or codec from the one you intended.
If the connection cannot sustain the recommended target, lowering the bitrate may reduce the amount of data being sent, but it also moves away from YouTube’s recommendation and may affect image detail. YouTube’s minimum is not a guarantee that every connection will work at that rate. Make changes deliberately, retest, and compare the resulting stream-health messages. Do not infer that a particular lower setting is safe merely because the stream appeared to work briefly.
If the stream is stable but the picture is not as clear as you expect, first verify the incoming resolution, frame rate and codec. Check that the source itself has the detail you expect, and ensure that the encoder is not scaling or otherwise altering it unintentionally. Increasing bitrate cannot restore detail absent from the source. Conversely, setting a higher bitrate than the connection can deliver can make a stream less reliable rather than clearer to viewers.
For a channel where keeping a computer on overnight is itself the weak point, StreamNeo can remove that particular burden: you upload the video and provide the YouTube stream key, then the live broadcast can run with your own computer switched off and be monitored and restarted if it drops. The bitrate and source settings still need to match the live guidance, and you should check the stream health rather than treating any hosting arrangement as a substitute for testing.
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
Does prerecorded footage use YouTube’s live bitrate settings?
Yes, if you send it through an encoder as a live event. Use the live-ingestion recommendations for the incoming resolution, frame rate and codec; use the separate upload guidance only when submitting a normal video file through YouTube Studio.
Is the recommended bitrate different for 720p30 and 720p60?
In YouTube’s listed 720p live table, the recommendation is the same at both frame rates: 8 Mbps for H.264, or 6 Mbps for AV1 and H.265/HEVC. The minimums are also the same within each codec family: 3 Mbps for H.264 and 2 Mbps for AV1 or H.265.
Does using the recommended bitrate guarantee a stable stream?
No. The recommendation is a live encoding target, while stability depends on whether the upload connection can carry the feed consistently and on the rest of the setup. Test with representative material and monitor YouTube’s stream-health messages during the event.
Should I manually select 720p in Live Control Room?
YouTube recommends automatic detection by default. If you need to set the resolution manually, follow its instructions for a custom stream key and manual resolution settings, and make sure the encoder sends the matching input.