Logo

MonoCalc

/

Live Stream Bitrate Calculator

Social Media
Arithmetic on the numbers you type

This tool does not test your connection. The upload capacity is a number you type in from your own speed test, and the arithmetic is only as good as that figure.

Whatever your encoder is set to.
Counted in the total, and in the recording size.
Drive makers count in powers of 1,000; Windows Explorer counts in powers of 1,024 and still writes GB.
A label only. It is echoed in the summary and the export, and it drives no calculation — no bitrate is inferred from a resolution here.
Leave it blank to skip the headroom check.
The reserve covers protocol and packet overhead, other traffic sharing the line, and the way upload speed fluctuates. How much slack to hold back is your call, so the tool asks instead of assuming.

No platform ingest limits are stored here. They change, and they differ by partner status, codec and resolution — check the figure your platform publishes.

Total bitrate

6,160 kbps (6.16 Mbps)

Recording, 2 h

5.54 GB

decimal, 10⁹ bytes

Per hour

2.77 GB

Per minute

46.20 MB

5,544,000,000 bytes exactly, which is 5.54 GB or 5.16 GiB 1 GB = 1,000,000,000 bytes (decimal, powers of 1,000). The same byte count, two prefix conventions.

Upload budget

30.8% of the capacity you entered
Fits inside the reserve you set

9.84 Mbps of the 20.00 Mbps you entered is still free after the 20% reserve.

reserve 20%video 6.00 Mbpscapacity 20.00 Mbps0

Video 6.00 Mbps

Audio 160 kbps (2.6% of the total)

Reserve 20% = 4.00 Mbps

Headroom here is arithmetic, not a guarantee. Other devices on the connection, Wi-Fi interference, ISP peering at peak hours and the route to the ingest server all change minute to minute.

How the recording grows (Decimal (MB / GB / TB))

2.77 GB1 h5.54 GB2 h0GB
ElapsedRecording sizeBytes
1 h2.77 GB (decimal, 10⁹ bytes)2,772,000,000
2 hend of session5.54 GB (decimal, 10⁹ bytes)5,544,000,000

About This Tool

Live Stream Bitrate Calculator – Encoder Totals, File Size and Upload Headroom

Two numbers decide how a broadcast goes before a single frame reaches the ingest server: what your encoder is sending, and what your line can carry. This live stream bitrate calculator adds your video and audio bitrates into one outbound total, turns that total into the size of the local recording OBS or ffmpeg is writing alongside the stream, and compares it against an upload capacity you supply. Every step is plain arithmetic on figures you typed, performed in your browser, with no network call of any kind.

Bits go out, bytes land on disk

Bitrate is counted in bits per second. File size is counted in bytes. Eight bits make one byte, so the conversion is a division by 8 — and getting that division backwards, or skipping it, is the single most common error in this calculation. It produces an answer wrong by a factor of eight in either direction, which is the difference between a session that fits your drive and one that stops recording halfway through.

Take 6000 kbps of video and 160 kbps of audio over two hours. The total is 6160 kbps, which is 6,160,000 bit/s. Two hours is 7200 seconds, so the session carries 44,352,000,000 bits. Divide by 8 and you have 5,544,000,000 bytes. The working-out panel prints that division on a line of its own, labelled, using your own numbers.

5.54 GB and 5.16 GiB are the same file

Bitrates are always decimal: 1 kbps is exactly 1,000 bit/s and 1 Mbps is exactly 1,000,000 bit/s, never 1,048,576. File sizes are where the ambiguity lives. Under decimal prefixes — what drive manufacturers and most streaming documentation use — 1 GB is 1,000,000,000 bytes, so those 5,544,000,000 bytes read as 5.54 GB. Under binary prefixes, the unit is a gibibyte of 1,073,741,824 bytes, so the same file reads as 5.16 GiB. Windows Explorer counts in binary and still writes “GB” on the label, which is why a file you calculated at 5.54 GB appears as 5.16 GB when you look at the folder.

Nothing changed but the divisor. The units toggle switches which convention every size output uses, each figure is labelled with the convention it actually used, and the byte count is printed in full so the two readings can always be reconciled.

What the headroom reserve is for

An encoder never gets the whole wire. Protocol and packet overhead take a share, other devices on the connection compete for the rest, and real upload speed fluctuates rather than sitting flat at whatever a speed test reported. The reserve is the slack you hold back from your stated capacity to absorb all of that, and it is a field you set rather than a constant this tool asserts, because how much slack a connection needs depends on the connection.

The bandwidth bar draws the outcome in three distinct states: the stream sits inside the reserve, it fits the line rate but reaches past the reserve, or it runs past the capacity altogether — in which case the segments overflow the capacity line and the shortfall is labelled as a positive magnitude. No negative headroom is ever printed as a number.

This tool measures nothing
There is no speed test here, no platform API and no ingest-server lookup. The upload capacity is a figure you type in from a test you ran yourself, and the tool cannot see congestion: shared household bandwidth, Wi-Fi interference, peering at peak hours and the route to the ingest server all change minute to minute. A pass here is arithmetic headroom, not a stable stream.

Why there is no resolution-to-bitrate table

Platform ingest guidance changes, differs by partner status, and depends on the codec and the content — a static talking-head scene and a fast-panning game at the same resolution do not need the same bitrate. Hard-coding a lookup would mean shipping figures that quietly go stale, so the resolution and framerate field here is a label: it is echoed back in the summary and the CSV, and it drives no calculation. Container and muxing overhead is left out for the same reason — its size depends on codec, keyframe interval and container, so the real wire rate sits slightly above the sum of the two streams rather than at an invented multiple of it.

The storage readout turns the total into the figure a creator with a nearly-full drive actually needs: how much the recording has grown at one hour, two hours, four, and at the end of the session, alongside the per-hour and per-minute rates for planning the next one. Copy the summary as plain text or export the whole thing as CSV — every exported cell is quoted, and any cell opening with =, +, - or @ is neutralised so a spreadsheet reads your resolution note as text rather than a formula.

Frequently Asked Questions

Is the Live Stream Bitrate Calculator free?

Yes, Live Stream Bitrate Calculator is totally free :)

Can I use the Live Stream Bitrate Calculator offline?

Yes, you can install the webapp as PWA.

Is it safe to use Live Stream Bitrate Calculator?

Yes, any data related to Live Stream Bitrate Calculator only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.

Why is my recording eight times bigger than I expected?

Because bitrate is counted in bits and file size is counted in bytes, and eight bits make one byte. A 6,000 kbps stream is 6,000,000 bits every second, which is 750,000 bytes every second — not 6 MB. Multiplying where you meant to divide, or skipping the step altogether, is the single most common error in this calculation, which is why the working-out panel prints the division by 8 on a line of its own.

Why does my 5.54 GB file show as 5.16 GB in Windows?

It is the same file; the two numbers use different definitions of the prefix. Drive manufacturers and most streaming documentation use decimal prefixes, where 1 GB is 1,000,000,000 bytes. Windows Explorer labels its figures GB but counts in binary, where the unit is really a gibibyte of 1,073,741,824 bytes. The byte count never changes — 5,544,000,000 bytes is 5.54 GB and 5.16 GiB at once. The units toggle switches which convention every size output uses, and each figure is labelled with the one it used.

Why leave any upload headroom at all?

Because the encoder never gets the whole wire. Protocol and packet overhead take a share, other devices on the connection compete for the rest, and real upload speed fluctuates rather than sitting flat at the figure a speed test reported. Running the total right up against the measured capacity leaves nothing for any of that. How much to hold back depends on your connection, so the reserve is a field you set rather than a constant the tool asserts.

Does this tool test my internet connection?

No. It makes no network calls at all — no speed test, no platform API, no ingest-server lookup. The upload capacity is a number you type in from a speed test you ran yourself, and every result is arithmetic on the figures you entered. It also cannot see congestion: shared household bandwidth, Wi-Fi interference, peering at peak hours and the route to the ingest server all change minute to minute, so a pass here is arithmetic headroom rather than a promise of a stable stream.

Why doesn't it tell me what bitrate to use for 1080p60?

Because there is no single figure to give. Platform ingest guidance changes, differs by partner status, and depends on the codec and the content — a static scene and a fast-panning game at the same resolution do not need the same bitrate. Hard-coding a lookup table would mean shipping numbers that quietly go stale. The resolution and framerate field here is a label: it is echoed back in the summary and the export, and it drives no calculation.

Does audio bitrate matter for the file size?

It counts, but it is a small share. At 6,000 kbps of video and 160 kbps of audio, audio is about 2.6% of the total, and the bandwidth bar shows it as a thin sliver beside the video segment. Over a long session that sliver is still real storage — 160 kbps is roughly 72 MB per hour — so it is added to the total rather than dropped. Container and muxing overhead is not modelled, because its size depends on the codec, keyframe interval and container, so the real wire rate sits slightly above the sum of the two streams.