Live Streaming Bandwidth Planner

Introduction to live upload bandwidth budgeting

Every live broadcast is, from the network's point of view, a single sustained upload that must not falter for the entire duration of the show. The encoder produces a compressed elementary stream at some target bitrate, the muxer wraps video and audio together, and a transport such as RTMP over TCP or SRT over UDP pushes the result to a platform ingest endpoint. If the uplink cannot sustain that rate for hours at a time, the encoder's send buffer fills, frames are discarded before they ever leave the building, and viewers see the stutter that no amount of post-production can undo. This planner converts an encoder configuration into the two numbers that actually decide whether a broadcast survives: the sustained uplink rate in megabits per second that you must provision, and the data volume in gigabytes that the broadcast will consume against an ISP cap or a metered cellular plan.

Two arithmetic mistakes dominate this subject, and both are handled explicitly here. The first is the confusion of bits with bytes. A bitrate of 8 Mbit/s is not 8 megabytes per second; a byte is exactly eight bits, so 8 Mbit/s is 1 MB/s. The second is the silent mixing of decimal and binary prefixes. In the International System of Units a megabit is ${10}^6$ bits and a gigabyte is ${10}^9$ bytes, whereas the IEC binary prefixes define a mebibyte as $2^{20}$ bytes and a gibibyte as $2^{30}$ bytes. Dividing megabytes by 1024 and calling the answer gigabytes, a pattern this page previously contained, produces a figure that is neither GB nor GiB and is wrong by 2.4 percent. Both conventions are reported side by side below so that nothing has to be guessed.

A third mistake is conceptual rather than arithmetic, and it is worth stating plainly at the outset: the number of concurrent viewers does not change what you upload. You transmit one copy of the stream to the ingest endpoint and the platform's content delivery network replicates it. A calculator that multiplies your uplink requirement by an audience size is not slightly pessimistic, it is wrong by orders of magnitude. Audience size affects your uplink only if you are also serving the distribution yourself.

How to use the planner inputs correctly

1. Number of contribution feeds is how many independent encoded streams leave your network at once. A four-camera shoot cut down to a single program feed by a switcher is one feed, not four. Count four only if all four cameras are separately encoded and sent upstream, as with remote contribution or multi-angle ingest.
2. Video bitrate per feed is the encoder's target rate in Mbit/s. Use the preset selector to load a value straight from the published platform ladder in the comparison table below, or type your own. For variable bitrate encoding, enter the configured peak cap, not the average.
3. Audio bitrate is entered in kbit/s and converted internally by dividing by 1000, because both prefixes are decimal. YouTube's live encoder documentation specifies 128 kbit/s for stereo and 384 kbit/s for 5.1 surround.
4. Protocol overhead covers the bytes that carry your payload but are not your payload: IP and TCP headers, TLS records, RTMP chunk headers, and retransmissions. The floor is computed below; 10 percent is a defensible planning value for RTMP over TCP.
5. Safety margin is the headroom you provision on top of the wire rate. Entering 50 percent means provisioning 1.5 times the wire rate, which is the low end of common production practice.
6. Measured sustained upload is what your link genuinely delivers over several minutes of continuous upload, not the figure on the invoice and not a two-second burst test. The planner grades your headroom against it and solves for the highest video bitrate the link can carry.
7. Hours streamed per week drives the data-volume estimate. The planner converts to a mean Gregorian month rather than a flat four weeks.

The bandwidth formula, layer by layer

Let $N$ be the number of contribution feeds, each encoded at $B_v$ megabits per second of video. Program audio is carried at $A$ kilobits per second. Protocol overhead is the percentage $O$, and the planning headroom is the percentage $M$. Three distinct rates follow, and keeping them distinct is what stops a plan from quietly under-provisioning. The payload rate $B_s$ is what the muxer emits:

Formula: B_s = N ⁢ B_v + A / 1000

$$B_s=N{B}_v+\frac{A}{1000}$$

The divisor 1000 is exact rather than conventional: the SI prefixes kilo and mega are ${10}^3$ and ${10}^6$ respectively, so kilobits per second convert to megabits per second by a clean factor of one thousand. Binary prefixes never enter a bitrate calculation. Applying protocol overhead gives the wire rate $B_w$, which is what a router or an ISP meter actually observes:

Formula: B_w = B_s ⁢ (1 + O / 100)

$$B_w=B_s(1+\frac{O}{100})$$

The overhead percentage is not arbitrary. On a standard 1500-byte Ethernet MTU an IPv4 header consumes 20 bytes and a TCP header consumes a further 20, leaving a 1460-byte maximum segment size. The unavoidable header cost relative to payload is therefore

Formula: O_min = (20 + 20) / 1460 ≈ 2.74%

$$O_{\min }=\frac{20+20}{1460}\approx 2.74\%$$

Add Ethernet framing, TLS record overhead on an encrypted ingest, RTMP chunk headers, and the TCP retransmissions that any real path produces, and 5 to 10 percent is the realistic planning band. Ten percent is used as the default here and is a stated assumption rather than a standardised constant.

Finally, the uplink to provision $U$ adds planning headroom on top of the wire rate. A link sized exactly at the wire rate has no capacity left for a retransmission burst, a cloud backup waking up, or the ordinary evening congestion of a shared access network, so provisioning at 100 percent of measured capacity is the classic way to build a broadcast that fails in its second hour:

Formula: U = B_w ⁢ (1 + M / 100)

$$U=B_w(1+\frac{M}{100})$$

Common production practice is a headroom factor of 1.5 to 2, that is $M$ between 50 and 100. No standards body publishes this figure, so it is presented here as an operational convention and a stated assumption, not as a sourced constant. The planner also inverts the relationship. Given a measured sustained uplink $U_m$ and a target headroom factor $k=1+M/100$, the largest video bitrate each feed can safely carry is

Formula: B_v,max = 1 / N (U_m / (k ⁢ (1 + O /100)) − A / 1000)

$$B_{v,\max }=\frac{1}{N}(\frac{U_m}{k(1+O/100)}-\frac{A}{1000})$$

and the achieved headroom on the current settings is simply the ratio $h=U_m/B_w$, which the result panel grades against your target.

Bitrate ladder comparison across codecs, resolutions and frame rates

The table below reproduces the live ingest ladder published by YouTube in Choose live encoder settings, bitrates, and resolutions. It is the platform operator's own technical documentation, cited as such. The first three numeric columns are YouTube's published figures; the last two are derived here with the arithmetic above, so you can see immediately what each rung costs in data volume and in provisioned uplink. Note the codec-generation effect: at 1080p60 the modern codecs are accepted from 4 Mbit/s while H.264 is recommended at 12 Mbit/s, a threefold difference in uplink for nominally the same rung.

The GB-per-hour column is video only and follows from the conversion in the next section: $1$ Mbit/s sustained for one hour is $3600÷8000=0.45$ GB. The uplink column adds a 128 kbit/s stereo audio track, applies 10 percent protocol overhead and a 1.5 headroom factor, so it equals $(B_v+0.128)\times 1.65$. Every preset in the calculator's selector is drawn from the H.264 column and the modern-codec bounds of this table.

The three codecs referenced are defined by the following standards. The practical point for a broadcaster is that ingest support, not theoretical efficiency, decides which one you may actually use: a platform that accepts only H.264 will make you pay the H.264 bitrate no matter what your encoder is capable of.

Converting a bitrate into a data volume without losing a factor of eight

Data volume is bitrate multiplied by duration, and the only two conversions involved are the definition of the byte and the choice of prefix. IEC 80000-13 defines the bit and the byte and fixes the relation $1\text{B}=8\text{bit}$. For a wire rate $B_w$ in Mbit/s sustained over $t$ seconds, the volume in bytes is exact:

Formula: V_B = (B_w ⁢ 10^6 ⁢ t) / 8

$$V_{\text{B}}=\frac{B_w{10}^{6}t}{8}$$

Expressed with the SI prefixes that NIST Special Publication 811 governs, and with the IEC binary prefixes, the same volume is

Formula: V_GB = (B_w ⁢ t) / 8000, V_GiB = (B_w ⁢ 10^6 ⁢ t) / (8 ⁢ 2^30)

$$V_{\text{GB}}=\frac{B_{w}t}{8000},V_{\text{GiB}}=\frac{B_w{10}^{6}t}{82^{30}}$$

The two differ by the factor $2^{30}/{10}^9\approx 1.0737$, so a volume quoted in GiB is about 7.4 percent smaller in number than the same volume quoted in GB. Mixing the two, or dividing megabytes by 1024 and labelling the result GB, is the defect that this page previously shipped: it understated every monthly figure by 2.4 percent. The planner now reports both units, each correctly labelled.

The second correction concerns the calendar. A month is not four weeks. The mean Gregorian month is

Formula: W = 365.2425 / (12 × 7) = 4.348125 weeks

$$W=\frac{365.2425}{12\times 7}=4.348125\text{weeks}$$

so for $H$ hours streamed per week the monthly duration in seconds is $t=3600HW$. Using a flat four weeks, as this page previously did, understates the month by 8.7 percent. Combined with the prefix error, the old monthly figure was low by about 10.2 percent, which is exactly the sort of quiet shortfall that turns into an overage bill.

Unit reference for every quantity on this page

Because bitrates are decimal and storage is often binary, the planner states the exact definition of every unit it uses. The values below are those fixed by the SI, as set out in NIST Special Publication 811, and by IEC 80000-13 for the binary prefixes and for the units bit and byte.

A worked example: one 720p60 feed on a 25 Mbit/s uplink

Take the values the planner loads by default. One contribution feed, video at 6 Mbit/s, which is YouTube's recommended H.264 rate for 720p60, stereo audio at 128 kbit/s, 10 percent protocol overhead, a 50 percent safety margin, a measured sustained uplink of 25 Mbit/s, and 8 hours of streaming per week.

The payload rate is $1\times 6+128/1000=6.128$ Mbit/s. Applying overhead gives a wire rate of $6.128\times 1.10=6.7408$ Mbit/s, and applying the safety margin gives an uplink to provision of $6.7408\times 1.50=10.11$ Mbit/s. The achieved headroom on the measured link is $25/6.7408=3.71$, comfortably above the 1.5 target, and the inverse solve says the link could carry a video bitrate of up to $25/1.65-0.128=15.02$ Mbit/s at that same margin, which is enough to move up to the 1440p30 rung.

For data volume, one hour at the wire rate is $6.7408\times 3600÷8000=3.033$ GB, equivalently 2.825 GiB. Eight hours a week over a mean Gregorian month is $8\times 4.348125=34.785$ hours, so the monthly total is $3.033\times 34.785\approx 105.5$ GB, or 98.3 GiB. Against a 1.2 TB cap that is 8.8 percent of the allowance; against a 100 GB cellular backup plan it would exhaust the entire month's data with the show still running.

Interpreting the numbers the planner returns

The three rates answer three different questions and should not be substituted for one another. The payload rate is what you type into the encoder. The wire rate is what a router graph or an ISP meter will show and what your data cap is charged against. The uplink to provision is what you should buy or reserve, and it is the only one of the three you should compare against a service tier.

The headroom ratio is the number to watch. Below 1.0 the plan is arithmetically impossible and the stream will drop frames from the first minute. Between 1.0 and your target the plan works on a quiet network and fails when anything else competes for the link. At or above the target you have absorbed the ordinary variance of a consumer or venue connection. If the ratio is very large, you are leaving quality on the table and should consider the next rung up the ladder, which is exactly what the maximum sustainable video bitrate figure tells you.

One caution about measuring the uplink in the first place. Consumer speed tests report a short burst, and many access networks grant a temporary boost that expires after a few seconds. A broadcast is a multi-hour sustained transfer, so measure with a sustained upload of at least a few minutes, or with the streaming platform's own bandwidth test, and enter that lower figure.

Encoder settings that change the answer

Rate control comes first. Twitch's engineering blog post Better Broadcasting with CBR states plainly that variable bitrate is bad for video over the internet because of the way TCP works and that you should use CBR whenever possible: VBR lowers the rate during static scenes and then spikes it during motion, and it is that spike, not the average, that exceeds the uplink and starves the encoder. If you nonetheless run VBR, plan against the peak cap you configure.

Keyframe interval comes second. YouTube's live encoder documentation recommends a keyframe every 2 seconds and instructs broadcasters not to exceed 4 seconds. For a frame rate $f$ and a keyframe period $t_k$ in seconds, the group-of-pictures length is

Formula: G = f ⁢ t_k

$$G=f{t}_k$$

so 60 fps at 2 seconds is a 120-frame GOP. Shortening the interval inserts more intra-coded frames, which are the expensive ones, and therefore raises the bitrate required for a given quality; lengthening it delays the moment a new viewer or a recovering connection can begin decoding. The planner does not model this cost directly, because it depends on content, but it is the usual explanation when a stream looks worse than its bitrate suggests it should.

Codec choice comes third, and it is constrained by what the platform will ingest rather than by what your encoder supports. The ladder table above shows the practical consequence: where a platform accepts AV1 or H.265, the 1080p60 rung opens at 4 Mbit/s, and where only H.264 is accepted the same rung is recommended at 12 Mbit/s. That is the difference between a 1080p60 broadcast fitting inside a modest uplink and not fitting at all.

Limitations, assumptions, and what this planner does not model

The arithmetic here is exact, but several of the inputs are conventions rather than constants, and it is worth being explicit about which is which.

• The 1.5 to 2 times headroom factor is common production practice. No standards body publishes it. It is offered as a stated assumption and is fully under your control through the safety margin field.
• The 10 percent protocol overhead default is a planning value, not a measurement. The 2.74 percent IPv4-plus-TCP floor derived above is exact for a 1460-byte segment; everything above it depends on your transport, on whether ingest is encrypted, and on the retransmission rate of your particular path. A clean fibre link may sit near 5 percent, a congested or lossy path well above 10.
• The mean Gregorian month of 4.348125 weeks is exact by definition but is an average. An individual month varies from 4.0 to 4.43 weeks, so a single billing period can differ from the estimate by around 3 percent in either direction even when everything else is right.
• The planner counts the encoded payload plus your stated overhead. An ISP meter counts every byte on the wire, including retransmissions you did not predict and any other traffic sharing the link. Treat the monthly figure as a floor for the stream itself, not as a prediction of your whole household bill.
• Concurrent viewers are deliberately absent from every formula. The platform's content delivery network handles fan-out. Adding a viewer multiplier would be a category error, and it is the largest single mistake found in bandwidth calculators of this kind.
• The planner models a single sustained rate. It does not model bonded or failover links, adaptive bitrate ladders generated on your own hardware, SRT retransmission buffers, or the burst behaviour of a specific encoder. For those, use this figure as the per-path budget and size each path separately.
• Platform bitrate ladders change. The figures reproduced above were taken from the operators' own current documentation, but ingest limits are business decisions and are revised without notice. Check the platform's page before a high-stakes broadcast.

Sources

Unit definitions and conversions: NIST, Guide for the Use of the International System of Units (SI), Special Publication 811, 2008 edition, A. Thompson and B. N. Taylor (nist.gov/pml/special-publication-811); NIST, Prefixes for binary multiples (physics.nist.gov/cuu/Units/binary.html); IEC 80000-13:2025 Edition 2.0, Quantities and units - Part 13: Information science and technology, published 11 February 2025, which specifies the units bit and byte and the prefixes for binary multiples and replaces the 2008 first edition (webstore.iec.ch/en/publication/87379). Codec standards: ITU-T Recommendation H.264 (08/2024), Advanced video coding for generic audiovisual services, published jointly with ISO/IEC as ISO/IEC 14496-10 (itu.int/rec/T-REC-H.264); ITU-T Recommendation H.265 (01/2026), High efficiency video coding, published jointly with ISO/IEC as ISO/IEC 23008-2 (itu.int/rec/T-REC-H.265); Alliance for Open Media, AV1 Bitstream and Decoding Process Specification, version 1.0.0 with Errata 1 (aomediacodec.github.io/av1-spec). Platform operator documentation, cited as the operators' own technical guidance rather than as independent standards: YouTube Help, Choose live encoder settings, bitrates, and resolutions, source of the ingest ladder, the 128 kbit/s stereo and 384 kbit/s 5.1 audio figures, and the 2-second keyframe recommendation with a 4-second ceiling (support.google.com/youtube/answer/2853702); Twitch, Better Broadcasting with CBR, 21 February 2013, source of the CBR-over-VBR guidance (blog.twitch.tv). No Twitch bitrate ladder is reproduced here: the Twitch help-portal article on broadcasting guidelines could not be retrieved as machine-readable text at the time of writing, so rather than quote figures that could not be verified against the operator's own page, none are given. The 1.5 to 2 times uplink headroom factor and the 10 percent default protocol overhead are stated assumptions reflecting common production practice, not sourced constants.

Frequently asked questions about stream bandwidth