Start by choosing the destination, codec, resolution and frame rate before setting a bitrate. There is no single value that suits every live stream: YouTube’s recommendations change with the format, and your connection must sustain the chosen value continuously.
When a stream becomes unstable, investigate the route to the ingest server before assuming the encoder is producing poor video. Test with movement and audio similar to the real broadcast, then adjust bitrate, connection, encoder and latency in that order.
Start with the destination and format
Your first setting is not the bitrate. It is the combination of platform, codec, resolution and frame rate that the stream is meant to use. A 1080p stream at 60 frames per second sends a different amount of video from a 720p stream at 30 frames per second, even before the content itself is considered.
YouTube publishes separate guidance for H.264 and AV1 or H.265. Its current table recommends the following ingest bitrates:
| Format | H.264 | AV1 or H.265 |
|---|---|---|
| 720p30 | 8 Mbps | 6 Mbps |
| 720p60 | 8 Mbps | 6 Mbps |
| 1080p30 | 14 Mbps | 10 Mbps |
| 1080p60 | 17 Mbps | 12 Mbps |
| 2160p60 | 50 Mbps | 35 Mbps |
These are YouTube’s recommendations, not a promise that your broadband connection can carry them. They are also not interchangeable. If your encoder is set to H.264, use the H.264 column rather than choosing the lower AV1 or H.265 figure simply because it looks more convenient.
Check the destination’s current requirements before making a profile. YouTube’s official live encoder settings cover supported protocols, codecs, frame rates and bitrate guidance. The published requirements include CBR, a recommended keyframe interval of two seconds, and a keyframe interval that should not exceed four seconds. YouTube supports RTMP and RTMPS, and recommends RTMPS because it encrypts the data sent to and through Google’s servers.
The format should also reflect the material. A devotional image with slow transitions, a lofi loop with gentle camera movement and a local news sequence with scrolling text do not put the same demands on an encoder or connection as a sports replay or gaming capture. That does not remove the platform’s requirements, but it affects how obvious compression will be when you test.
For a pre-recorded YouTube broadcast, decide whether you need 30 or 60 frames per second before you export or configure the stream. If the source was created at 30 fps, sending it at 60 fps does not create new detail. It can increase the work required while offering little visible benefit. The YouTube Live Stream Bitrate Settings for a Pre-Recorded Video explains why the source file and the live output should be considered together.
Choose a bitrate your connection can sustain
A destination-supported bitrate is only a starting point. Your upload connection needs to maintain it during the whole broadcast, including periods when household or office traffic changes. A speed test taken during a quiet moment is evidence about that moment, not a guarantee for an overnight stream.
OBS describes dropped frames as a sign that the connection to the remote server is unstable or that the stream cannot keep up with the configured bitrate. Its stream connection troubleshooting guide suggests using 75% of total upload speed as a troubleshooting starting point, while also taking account of the platform’s limits and the stability of the connection.
Treat that 75% figure as a heuristic, not as a rule that overrides YouTube’s format guidance. For example, if the chosen YouTube profile calls for 17 Mbps but your connection cannot reliably provide enough upload capacity with room for ordinary variation, the profile is not sustainable. Lowering the output resolution or frame rate may be more sensible than repeatedly forcing a bitrate that the connection cannot carry.
Leave room for traffic that is not part of the video stream. Cloud backups, security cameras, video calls, software updates and other users can compete for upload capacity. A wired connection can make testing more predictable, but an Ethernet cable will not solve ISP congestion, a failing router or an overloaded encoder.
Do not confuse bitrate with file size. A file uploaded to a cloud service can arrive slowly and still play later. A live ingest connection has to deliver the stream in time. If the outgoing data falls behind, the destination may report dropped frames, a degraded stream or a disconnection.
For a channel that runs continuously, choose the lowest profile that gives the required visual result and remains sustainable during a representative test. A devotional channel with a mostly static background may not need the same profile as a rapidly changing replay channel, but text, fine patterns and moving backgrounds still deserve inspection. Lower bitrate is not automatically better; it is useful only when it leaves the connection with enough margin to remain steady.
Test the picture with representative movement
A still image is a poor test of a live configuration. It can hide blockiness, smearing and sudden bitrate pressure because very little changes from one frame to the next. Test with the movement that will actually occur: a camera pan, a scrolling news strip, a music visualiser, people moving across the frame or a scene change between programme segments.
Include the intended audio as well. Audio faults can be missed when you test a silent file, and a stream that looks good may still have clipping, gaps or an unexpected delay. YouTube recommends testing with movement and audio similar to the planned live event, then monitoring stream health during the broadcast.
A useful test has three parts:
- Use the final resolution, frame rate, codec and keyframe settings.
- Play the most demanding ordinary section of the source, rather than an unusually simple opening frame.
- Watch both the local encoder statistics and the destination’s stream-health messages.
If the local preview shows a clean picture but the platform reports dropped frames, the problem may be between the encoder and the ingest service. If the platform receives the stream without dropped frames but the local encoder reports rendering or encoding delay, the problem is more likely inside the computer or the encoder settings. These are different failures and need different changes.
Look at fine detail as well as large objects. Text in a news ticker, the edge of a singer’s face, smoke, tree leaves, a patterned curtain and dark gradients can reveal compression that is not obvious in a bright, still scene. Watch a full section long enough for the connection and encoder to encounter ordinary variation, rather than judging the first few seconds.
If you are building a devotional or music loop, the guide to running a nonstop gospel music stream on YouTube from a playlist is relevant to the content workflow. The same testing principle applies whether the source is one long video or a sequence of shorter items: test the material that creates the greatest movement and audio demand.
Diagnose dropped frames before changing quality
Dropped frames do not automatically mean that the encoder quality is too low. First identify which part of the chain is failing. A live stream normally involves the source, the encoder, the local network, the route to the platform’s ingest server and the platform receiving the data. A fault in any one of these can appear as an unreliable stream.
Start with the statistics available in the streaming software. Separate connection-related dropped frames from rendering or encoding delay where the software provides those categories. Then check the destination’s stream-health view. If the encoder is unable to process frames in time, lowering output complexity may help. If the connection is dropping frames, changing a visual quality setting alone may not address it.
Use this sequence:
1. Check the ingest route
Try another available ingest server or endpoint where the platform permits it. OBS recommends this because one route can be unstable while another performs normally. A good result on one server does not prove that your broadband connection is perfect, but it helps identify whether the issue is route-specific.
2. Lower the video bitrate
Reduce the bitrate to a value the connection can maintain, while staying within the destination’s requirements for the selected format. Make one change at a time and observe the result. If the drops stop after the reduction, the previous setting exceeded the practical capacity of the connection or its route.
3. Test whether the service is specific to the problem
If appropriate for your workflow, test the connection against another live destination. A problem on one service may indicate an ingest or routing issue rather than a general failure of the computer. This is a diagnostic test, not a reason to move a channel without checking its own requirements.
4. Remove local interference
VPNs, security software and bundled network utilities can interfere with streaming software. Check whether the problem began after an update or configuration change. On Windows, OBS also documents network optimisation and TCP pacing settings that some users report as helpful, but these should be treated as troubleshooting options rather than guaranteed fixes.
5. Compare Wi-Fi with Ethernet
OBS recommends a wired connection when streaming because Wi-Fi can be unstable. Test Ethernet directly rather than assuming that a strong Wi-Fi signal means a consistent upload path. If the wired test still drops frames, the fault may be elsewhere in the network or with the ISP.
6. Check the wider network
Inspect the modem, router and other active devices. Congestion or a change on the ISP’s side may be outside your control, so contact the ISP if the issue persists across tests. Keep notes about the time, ingest server, bitrate and connection type; a pattern is more useful than a general report that the stream sometimes fails.
Dynamic bitrate can reduce dropped frames by lowering the outgoing bitrate when the connection cannot keep up. It is a fallback, not a repair. The picture quality falls as the bitrate falls, and the underlying connection problem remains. For a channel that must look consistent, finding and correcting the cause is preferable where possible.
Adjust latency with platform trade-offs in mind
Latency is the delay between an event happening and viewers receiving it. Reducing that delay can help when viewers need to respond quickly, such as during a live conversation or a local update. It can also change the platform’s available quality options and leave less room for buffering.
Do not choose low latency simply because it sounds technically superior. A devotional loop, study channel or ambience station may gain little from reducing the delay, while a live presenter reading viewer messages may value a quicker exchange. The right choice depends on how the audience uses the stream.
On YouTube, latency is tied to the selected stream configuration. YouTube states that low latency is unavailable for 4K or 2160p streams, which use normal latency. That is an important trade-off: if 4K is central to the channel, you cannot assume that the low-latency option will remain available.
Lower latency can also make interruptions more visible because the platform has less time to absorb variation in delivery. For a 24/7 station, a stable picture may matter more than shaving delay from a loop that viewers are not interacting with. For a news or discussion channel, the audience may accept different quality or buffering behaviour in exchange for a more immediate conversation.
Set latency after you have a stable format and bitrate. Changing latency while also changing resolution, codec and connection makes the test difficult to interpret. Record the setting and observe viewer-facing behaviour, platform health messages and any change in available resolutions.
Decide whether the computer should remain in the loop
If the stream is generated locally, the computer must remain powered, connected and able to encode for the full broadcast. Sleep settings, operating-system updates, Wi-Fi interruptions and a brief restart can all interrupt an otherwise correct configuration. The guide to keeping a 24/7 YouTube lofi stream running after Windows updates covers the operational side of that problem.
A cloud-based workflow can remove the need to leave your own computer running, but it does not remove the need to test the file, stream key, destination settings and resulting broadcast. StreamNeo is designed for the specific case where you upload a video once, add the YouTube stream key, and want the broadcast to continue while your computer is switched off, with automatic monitoring and restart when the stream drops.
That approach is useful when the recurring problem is local power, updates or overnight connectivity. It is not a reason to skip bitrate testing. The uploaded file and chosen live settings still need to produce a stream that YouTube can receive and viewers can watch.
If you prefer to operate the stream yourself, keep the encoder computer on a wired connection where possible and disable sleep during the planned broadcast. For a technical self-hosted setup, the FFmpeg YouTube stream in a Docker container on a VPS discusses a different operating model. Choose it only if you are comfortable maintaining the relevant software and monitoring the process.
Retest the complete stream before relying on it
After changing a setting, repeat the test from source to viewer. Do not judge success only by the local preview. Confirm that the destination receives the stream, that the intended resolution is available, that audio remains in sync and that health messages do not show a recurring fault.
Use the same source section, connection and ingest route when comparing two settings. If you change everything at once, you may obtain a better result without knowing why. A short record can include:
| Item to record | Example of what to compare |
|---|---|
| Codec | H.264 versus AV1 or H.265 |
| Output format | 720p30, 720p60, 1080p30 or 1080p60 |
| Video bitrate | The selected value and whether drops appeared |
| Connection | Wi-Fi or Ethernet, including other upload activity |
| Ingest route | The endpoint used during the test |
| Latency | Normal or the available lower-latency option |
| Result | Dropped frames, encoder delay, audio fault or clean delivery |
Run the final test with the equipment and network conditions you expect overnight. If the channel will run from India during a busy household period, test at a comparable time rather than only during a quiet afternoon. If the stream will carry scrolling text or rapid movement, include that material.
Once the configuration is stable, avoid changing several settings just to chase a small visual improvement. Save the encoder profile and note the date of the test. Recheck the platform’s official documentation when you change codec, resolution, frame rate or latency, because platform recommendations can change.
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 YouTube live stream?
Use the bitrate recommended by YouTube for your codec, resolution and frame rate, then confirm that your connection can sustain it. For example, YouTube lists different recommendations for 1080p60 H.264 and 1080p60 AV1 or H.265, so there is no universal 1080p value.
Why is my stream dropping frames?
Dropped frames usually point first to an unstable connection or a bitrate the connection cannot maintain. Try another ingest route, test Ethernet, remove possible software interference and lower the bitrate as a diagnostic step before changing the visual format.
Does lowering bitrate fix stream instability?
It can stop drops when the configured bitrate is greater than the practical upload capacity. It does not repair congestion, faulty network hardware or an ISP problem, and the lower bitrate may reduce picture quality.
How do I reduce live stream latency?
Choose a lower-latency option only after checking what the platform allows for your selected format. On YouTube, low latency is unavailable for 4K or 2160p streams, so reducing delay can mean giving up that resolution choice.