Average bitrate is file size in bits divided by duration in seconds. That is the whole calculation, and it runs backwards just as well: a target bitrate multiplied by duration gives you the file size you are about to pay to store and serve. A 900 MB file that plays for 10 minutes carries roughly 12 Mbps — 900 × 8 million bits, divided by 600 seconds.
The arithmetic is trivial. What people do with the result is not.
What does calculating the bitrate of a video actually tell you?
It tells you what the file cost, on average, per second of playback. It does not tell you what the video looks like. The same figure gets read as a quality dial — one number, stamped across every title and every device in the ladder — and that reading is where budgets go wrong. Computed once and generalised, the number overspends on simple content and starves complex content. Computed per content profile and per device class, the same arithmetic produces a defensible per-stream budget.
Three separate numbers hide behind the phrase “the bitrate of this video”, and they answer different questions:
| Figure | Formula | What it answers |
|---|---|---|
| Average bitrate | total bits ÷ duration in seconds | What the file cost to store and what egress will cost |
| Peak bitrate | highest bits delivered in one second (or one buffer window) | What network headroom and player buffer the stream demands |
| Bits per pixel per frame | bitrate ÷ (width × height × frame rate) | Whether two encodes are comparable across resolutions and codecs |
Only the third is portable. Raw bitrate cannot be compared between a 1080p25 rung and a 2160p50 rung, because the second is pushing roughly eight times as many pixels per second. Bits per pixel per frame normalises that out, which is why it is the figure worth carrying across a ladder review rather than the Mbps column everyone quotes.
Two things the file-size formula quietly includes
The divisor is duration; the numerator is every bit in the container, not just the video elementary stream. Audio and container overhead both land in it. If you compute 12 Mbps from a finished MP4 and hand that number to an encoder as a video target, you have silently over-budgeted the video by whatever the audio track and muxing overhead consume. Subtract the audio bitrate first, then treat the small remainder as container overhead rather than pretending it is zero.
The other quiet inclusion is variance. A variable-bitrate encode hits the average by construction, so the file-size arithmetic still holds — but the ceiling and buffer settings, not the average, are what determine whether a player on a constrained link can actually sustain the stream. Sizing storage from the average and sizing delivery from the average are two different mistakes wearing the same number.
From bitrate to cost per stream
This is where the calculation earns its keep. Average bitrate × stream duration × concurrent viewers is the egress bill, and the same average sizes the transcoding output storage for that rung. Once each rung of a ladder has a bits-per-pixel-per-frame figure attached, rungs that consume budget without moving measured quality become visible — they are the ones whose bits-per-pixel is far above their neighbours with no corresponding quality-of-experience gain.
Getting the per-rung arithmetic right is the precondition for measuring cost-per-stream before and after a ladder change at a held quality target. Without it, a ladder change is a guess with a spreadsheet attached. We treat this as the first measurement step when profiling an encoder pipeline for broadcast and streaming delivery work, before any codec or preset is touched.
Where the number stops being reliable
A computed bitrate is a poor proxy for delivered quality whenever content complexity or codec generation shifts underneath it. Fast motion, film grain, and high-detail sports feeds all consume bits that a talking-head encode never needs, so an average derived from one content class transfers badly to another. Codec generation matters the same way: the same 4 Mbps means something different coming out of an H.264 encoder than out of an HEVC or AV1 one. And single-pass encoding may simply miss the target you calculated, because the rate controller has no lookahead over the whole title to distribute bits against.
Check the calculation against the pipeline you actually run, not against the pipeline the formula assumes. The bitrate calculator explainer covers what those baked-in assumptions look like inside a tool.
If your ladder has a rung whose bits per pixel per frame is an outlier, what is it buying — and can you measure the difference?
