Start with 720p at 30 frames per second, H.264, constant bitrate and a two-second keyframe interval. YouTube lists 8 Mbps as the recommended H.264 video bitrate for 720p30, but that is an ingest recommendation, not a promise that every older computer or internet connection can sustain it.
Use 8 Mbps only as a starting point. Test the actual PC, upload connection, video movement and audio together before leaving the stream unattended, then reduce the bitrate or resolution if the connection or encoder cannot keep up.
Start with a modest stream target
A low-end PC has two separate jobs during a live stream. It must encode the video, and it must send the resulting stream continuously to YouTube. A setting can be reasonable for one job and unsuitable for the other.
That is why the useful question is not simply “What is the best bitrate for YouTube?” It is “What can this computer and this upload connection sustain for the scene I am actually broadcasting?” A static devotional image with gentle music places a different workload on the encoder from a screen recording with scrolling text, camera movement or several animated overlays.
For most older computers, begin with 720p30 rather than jumping to 1080p or 60 frames per second. This gives viewers a useful picture while avoiding the extra output size of 1080p and the additional frame production required by 60 fps. YouTube’s published figures describe what it expects to receive; they do not benchmark particular CPUs, graphics chips, hardware encoders or software presets.
This is especially relevant for an always-on channel. A computer that appears fine during a short test may become unreliable after running overnight, sharing resources with other applications, or dealing with a brief change in the scene. If you are building a devotional or bhajan channel, the practical starting point is usually a prepared 720p video with stable audio rather than a complicated live layout. The video-file encode checklist can help you remove unnecessary work before the encoder begins.
Do not treat “low-end PC” as a precise hardware category. Two machines with similar age can behave differently because of cooling, drivers, available memory, background software and whether encoding is handled by the processor or a supported hardware encoder. The test result from your own machine matters more than a label.
Set 720p30, H.264 and CBR
In your encoder, choose a 1280 by 720 output at 30 fps, H.264 video and CBR, meaning constant bitrate. Use progressive scan and square pixels. YouTube’s current live encoder guidance also lists AAC or MP3 audio, stereo audio at 128 kbps and 44.1 kHz sampling. For a straightforward first test, AAC stereo at those audio settings is a sensible match where your software offers it.
Choose RTMPS where your encoder supports it, because YouTube recommends the encrypted protocol for transmission. Your stream software will normally ask for the YouTube stream URL and stream key separately. Treat the key as a password: do not paste it into screenshots, public notes or a shared support post.
The important distinction is between output resolution and the source file. A 1080p source can be sent through a 720p output setting, but that does not create extra detail. It may still add scaling work. If your source is already 720p, avoid asking the computer to enlarge it and then reduce it again.
CBR makes the outgoing rate more predictable. That matters for a connection that is close to its limit, because large changes in the amount of data being sent can make the stream less stable. CBR does not solve an inadequate upload connection or an overloaded encoder, but it gives you a clearer baseline for testing.
YouTube also publishes guidance for B-frames, reference frames, CABAC and colour settings such as Rec. 709 for SDR. Use the documented defaults in your encoder where they are exposed, rather than changing several advanced controls at once. If your software uses different names or hides one of these settings, keep the main variables stable and focus first on resolution, frame rate, codec, bitrate and keyframe interval.
For a 24/7 workflow, simplicity is useful. A prepared loop with no browser sources, camera filters or animated scene transitions is easier to troubleshoot than a layout with many moving parts. If you are considering a spare computer for an always-on channel, see the guidance on setting up a YouTube channel with a spare PC, but still test the particular machine rather than assuming that spare hardware will cope.
Use 8 Mbps as a starting point, not a rule
YouTube’s H.264 table lists 8 Mbps as the recommended video bitrate for 720p30 and 3 Mbps as the minimum listed figure. The recommended figure is not a hard minimum, and it is not a guarantee of picture quality or stream stability. It is a useful reference for the data YouTube expects at that resolution and frame rate.
| H.264 target | YouTube-listed minimum | YouTube-listed recommended bitrate |
|---|---|---|
| 480p30 | 0.4 Mbps | 4 Mbps |
| 720p30 | 3 Mbps | 8 Mbps |
| 720p60 | 3 Mbps | 8 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
| 1080p60 | 6 Mbps | 17 Mbps |
These are YouTube ingest figures from its encoder guidance, not low-end-PC performance tests. The upload must carry the video and audio traffic, and it needs enough headroom for normal variation rather than operating at its absolute ceiling. A speed-test result is evidence about the connection at that moment, not a guarantee that the same capacity will be available throughout the night.
If your sustained upload cannot support 8 Mbps, lowering the bitrate is preferable to repeatedly dropping the stream. YouTube states that the total streaming bitrate cannot exceed available upload bandwidth. You may need to try a lower value and inspect the result, understanding that lower bitrate can produce more compression, especially around movement, text and detailed backgrounds.
Do not add the audio bitrate to the video field by guesswork. Set the video bitrate in the video encoder and the audio bitrate separately. The combined traffic still matters to the connection, but the encoder fields have different purposes.
A 720p30 stream at a lower bitrate may be a better practical choice than an unstable stream configured with the recommended number. For example, a small business showing a mostly static sign may tolerate a lower rate more readily than a study channel with fine text or a local news loop with scrolling headlines. The correct choice comes from viewing a representative test, not from treating one number as universally suitable.
Keep the keyframe interval at two seconds
Set the keyframe interval to two seconds. YouTube recommends a two-second interval and says it should not exceed four seconds. A keyframe is a complete reference frame; the frames between keyframes generally describe changes from earlier information. Regular keyframes make the stream easier for the platform to process and can help viewers join or recover from a stream cleanly.
At 30 fps, a two-second interval corresponds to a regular pattern of reference points across the stream. You do not need to calculate this manually if the encoder accepts the interval in seconds. Enter 2 where the field expects seconds, or use the equivalent setting in your software.
Avoid changing the interval to compensate for an overloaded PC or weak upload. It is better to address the main causes directly: lower the output resolution, lower the bitrate, remove expensive scene elements, close other applications or choose a less demanding encoder path that your particular computer supports. The keyframe setting is important, but it is not a general performance control.
If a stream guide or preset uses a longer interval, check the current YouTube encoder settings and bitrate guidance before copying it. Platform recommendations can change, and an old tutorial may describe a different interface or workflow.
Lower the settings when the upload cannot sustain them
When YouTube reports dropped frames caused by the connection, the first question is whether the outgoing rate is too close to the available upload capacity. Run a speed test at the location and time you intend to stream, then test the encoder while other normal household or office activity is present. The result should be treated as an indication, not proof of overnight capacity.
Reduce one major variable at a time. If 720p30 at 8 Mbps is unstable, try lowering the video bitrate while keeping 720p30. Watch the result. If the stream still drops frames or the picture becomes difficult to maintain, move to a lower resolution such as 480p30 and test again. YouTube’s table lists 4 Mbps as the recommended H.264 bitrate for 480p30 and 0.4 Mbps as its minimum listed figure, but the lower end can show visible compression and should not be selected without viewing the result.
If the upload is strong but the encoder is overloaded, reducing bitrate alone may not fix the problem. Lowering output resolution, reducing frame rate or simplifying the scene can reduce the amount of work. A 720p30 target is already a conservative choice compared with 1080p, but it remains a target to validate rather than a guarantee for unspecified hardware.
YouTube lists the same recommended 8 Mbps video bitrate for 720p60 as for 720p30. That does not mean the two modes place the same demand on your computer. At 60 fps the encoder produces twice as many frames each second, and the actual workload depends on the content and encoder implementation. If a low-end PC is your concern, test 30 fps first and only try 60 fps if you have a clear reason and a successful representative test.
Similarly, do not move to 1080p merely because the source file is 1080p. YouTube lists 14 Mbps as recommended for 1080p30 and 17 Mbps for 1080p60, with higher listed minimums than for 720p. That increases the demand on the upload and may increase the work required from the computer. A stable 720p broadcast is more useful than a higher-resolution stream that repeatedly buffers or stops.
If your objective is a long unattended broadcast rather than a short event, a simpler route can remove the need to keep a particular computer running. StreamNeo removes the overnight strain of leaving the encoder PC switched on by taking an uploaded video and running it as a YouTube live stream after you provide the stream key. You still need to check the file, channel and live-stream settings, but the day-to-day problem is no longer tied to that PC being powered continuously.
Test movement and audio before the event
YouTube’s own instruction is to test before starting your live stream. Make the test resemble the real broadcast instead of displaying a static desktop for a few minutes and assuming that the result applies to everything else.
For a devotional loop, include a section with a moving background, text overlays and the loudest or most detailed visual passage. For a study channel, test scrolling text, screen changes and any cursor movement. For a local news loop, include the ticker and transition graphics. For a small business, include the product shots, camera movement and any music or spoken introduction that will actually be used.
Listen to the audio as well as watching the image. Check that speech is understandable, music is not distorted and the audio does not slowly drift away from the picture. A clean video stream with missing or clipped audio is still a poor broadcast. Confirm that the correct microphone or source is selected and that another application is not taking control of it.
Run the test long enough to expose the behaviour you care about. The purpose is not to produce a universal duration or a false guarantee. It is to see whether the encoder remains stable while the representative scene, audio and ordinary background activity are present. Record the settings and any warnings so you can compare one change with the next.
YouTube recommends checking the preview and stream health before going public where the workflow allows it. Review the YouTube streaming tips for current advice on testing, connection checks and monitoring. If you are looping several files, also confirm the loop itself does not end when the first file finishes; a stable encoder cannot repair a playback workflow that stops at the end of the source.
Monitor stream health while live
During the broadcast, watch the encoder’s CPU or GPU load, dropped-frame indicators, frame rate and outgoing bitrate. Do not change settings merely because a number moves briefly. Look for a continuing pattern and compare it with YouTube’s stream-health messages.
Dropped frames caused by the network point towards upload capacity, route congestion or a bitrate that is too close to the connection’s limit. Encoder overload points towards the computer or scene workload. Skipped or delayed frames can indicate that the encoder cannot produce frames quickly enough. The exact labels vary by software, so read the message rather than treating every dropped-frame count as the same fault.
Keep the stream preview open where practical and check the public playback from another device or connection. This can reveal problems that are not obvious in the local encoder window, such as audio silence, an incorrect aspect ratio or a picture that is several seconds behind.
For an unattended channel, monitoring should not depend only on the screen beside the PC. If a stream matters overnight, arrange an alert or a check that reaches you when the broadcast stops or health degrades. The 24/7 stream monitoring guide covers the practical side of receiving useful alerts rather than discovering the failure the next morning.
If the stream is unstable, do not keep restarting it with the same settings and hope the next attempt will behave differently. Note the symptom, change one relevant variable and test again. A lower resolution or bitrate may be the right answer, even if it does not match the highest quality your source file could provide.
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
Is 8 Mbps the minimum bitrate for 720p YouTube live streaming?
No. YouTube’s H.264 table lists 3 Mbps as the minimum figure and 8 Mbps as the recommended figure for 720p30. The recommended number is a starting reference, not a hard requirement, and your available upload bandwidth may require a lower setting.
Should I use 720p30 or 720p60 on an older PC?
Start with 720p30. Although YouTube lists the same recommended H.264 bitrate for both modes, 60 fps requires the encoder to produce more frames each second, and YouTube does not publish a benchmark for unspecified low-end computers. Use 60 fps only after testing the actual machine and content successfully.
What should I change if the stream keeps dropping frames?
First identify whether the warning points to the connection or encoder workload. If upload capacity is the issue, lower the video bitrate and test again; if the computer is overloaded, simplify the scene or lower the resolution or frame rate. Check the result with movement and audio that match the real broadcast.
Can a speed test prove that my PC will stream all night?
No. A speed test informs you about connection capacity at a particular time, while the encoder test shows how the computer behaves with your actual content. YouTube recommends testing before the event and monitoring stream health and messages during it, but neither test creates a guarantee for every future session.