Bitrate is a quality dial, not a property of a resolution
There is no bitrate that a given resolution requires. The same 1920 by 1080 frame can be sent at 2 Mbps and look acceptable for a static talking head, or at 12 Mbps and still show artefacts on falling snow. What actually sets the requirement is how many pixels per second you are sending and how much information each of those pixels carries, and that second part is entirely about content.
The calculator works in bits per pixel per frame for exactly that reason. Multiply width by height by frame rate and you have pixels per second; multiply by a bits-per-pixel figure and you have a bitrate. Around 0.05 is thin and works for slow, clean, simple footage. Around 0.08 is a sensible general figure. Above 0.1 is where you go for fast motion, film grain, confetti, foliage, or anything else that gives an encoder no repetition to exploit. Working this way means you can see immediately what doubling the frame rate costs, which is the same as doubling the bitrate for the same look.
Upstream is the constraint, and it is smaller than you think
Residential connections are asymmetric, usually heavily. A service sold on a large download figure may provide a tenth of that upward, sometimes less, and the marketing rarely puts the upload number where you will see it. That asymmetry exists because most households consume far more than they send, which is a reasonable engineering decision that stops being reasonable the moment you become someone who sends.
So measure it, at the time you actually stream, more than once. An upload test at ten in the morning is not the number you will have at nine in the evening when everyone in the neighbourhood is watching something. And test on the connection you will use, not on a phone standing next to it. If the results vary by a wide margin between tests, plan against the worst one rather than the average, because a stream is a continuous commitment and it is judged by its worst minute.
Headroom is what stops it breaking
A stream configured to use exactly the available upload will fail, and it will fail in the least helpful way. Encoders do not produce a constant bitrate; they produce something around the target that spikes on hard scenes, which is precisely when you least want a stall. Meanwhile the rest of the household is not aware you are streaming. A video call starts, a phone backs up a few thousand photos, a game patches, and each of those takes upload without asking.
| What is competing | Rough upload it wants | Behaviour |
|---|---|---|
| Video call | 1 to 4 Mbps | Continuous, and adapts by degrading rather than stopping |
| Cloud photo or file sync | Whatever it can get | Bursty and greedy, often triggered by nothing you did |
| Backup software | Whatever it can get | Usually schedulable, which makes it the easiest to fix |
| Another stream or upload | Its own full requirement | Two streams on one link is two links worth of demand |
The headroom field defaults to 35 percent, which is a starting point rather than a recommendation. Set it against what actually shares your connection. If the answer is nothing at all, and the connection is stable, you can run tighter; if the answer is a household of four, 35 percent is optimistic and the fix is scheduling the backups rather than shrinking the stream.
Turning bitrate into gigabytes
The conversion is division by eight, since there are eight bits in a byte, and then the usual unit bookkeeping. A 6 Mbps stream is 0.75 megabytes per second, 2.7 gigabytes per hour, and about 108 gigabytes over a forty-hour month. That figure matters in two places: a metered connection where upload counts toward the cap, and any situation where the same footage also has to be stored. If the stream is also being recorded locally, size the recording side with the video file size calculator or the media file size calculator, and convert between units with the data size converter when the figures stop lining up.
What to give up when it does not fit
When the link cannot carry what you want, there are four levers and they are not equally costly. Frame rate is usually the cheapest to give up — halving it halves the bitrate requirement, and for most content the loss is far less noticeable than the artefacts you get from an underfed encoder at the higher rate. Resolution is the next lever, and downscaling to a lower resolution at a healthy bitrate consistently looks better than a starved stream at the higher one. A more efficient encoder buys real bitrate at the cost of more work for the machine, which is a trade the render time estimator deals with from the other direction. And finally there is scheduling everything else out of the way, which costs nothing and is the lever people try last.
The one thing not worth doing is setting a bitrate above what the link carries and hoping. That does not produce a lower-quality stream; it produces a stream that stalls, which viewers tolerate far less than softness.
Questions people ask
What bitrate should I use for 1080p60?
There is no single answer, which is why this calculator asks for bits per pixel instead of handing you one. At 0.08 bits per pixel, 1080p60 works out around 10 Mbps of video. Slow, clean content looks fine at half that; fast motion with grain wants considerably more. The binding constraint is usually not what looks good but what your upload carries with headroom, and what the destination service accepts — that last one is a published limit that changes over time, so check it at the source rather than trusting a figure from an article.
Why does my stream stutter when the speed test says I have plenty?
A speed test measures a short burst on an otherwise idle link. A stream is a continuous commitment competing with everything else in the household, and it is judged by its worst minute rather than its average. The usual culprits are a device syncing in the background, a video call, or upstream congestion at times of day you did not test. Bufferbloat is another: a link can show a high throughput number while adding enough latency under load to disrupt a real-time stream. Test at the hour you stream, with the household doing what it normally does.
Does a more efficient encoder mean I can stream at a higher resolution?
Sometimes, and it costs you elsewhere. A newer generation of encoder can deliver similar perceived quality at a meaningfully lower bitrate, which is real headroom. The trade is that it takes more computation to do so, either from the processor or from dedicated hardware, and that work happens at the same time as whatever else the machine is doing. The other constraint is what the receiving end accepts and what viewers can decode, which is a compatibility question rather than a bandwidth one. The efficiency selector here is deliberately relative rather than named, so it stays true as encoders change.
Does the upload count against a data cap?
Often, and people are caught out because they only think about downloads. Many metered connections count traffic in both directions, so forty hours of a 6 Mbps stream adds around 108 gigabytes a month before you have watched or downloaded anything. Some plans meter only downloads, some meter only at certain hours, and the terms are worth reading rather than assuming. The monthly total in the results is upload alone.
Is wired or wireless better for streaming?
Wired, where it is practical, and the reason is consistency rather than peak speed. Modern wireless can exceed a residential upload link comfortably on a good day, but it varies with interference, distance, and how many other devices are talking. A stream cares far more about a floor that never drops than about a high ceiling. If wireless is the only option, the useful moves are getting closer to the access point, using a less crowded band, and testing during the busiest hour rather than the quietest.