Sizing the uplink out of a venue: two numbers, not one

The venue's headline speed answers the wrong question

A venue advertising a gigabit connection sounds like a solved problem. It usually is not, for three reasons: the number describes download rather than upload, it is shared with everyone in the building, and it says nothing about stability under load.

What you need out of a venue is a contribution feed — one stream, from your encoder to your streaming platform. What delegates need is distribution, which is the platform's problem and not yours. Sizing one against the other is the most common error in this area.

Contribution: small, and it must never wobble

A single 1080p contribution feed at a sensible bitrate is 6 to 10 Mbps. Add a backup path and a return feed for comms and you are still under 25 Mbps.

That is a small number. Almost any venue can supply it on paper. The requirement that is hard is that it must be continuously available, because a contribution feed that drops for four seconds drops your stream for four seconds in front of everyone watching.

So the specification is not bandwidth. It is:

• //A committed rate, in writing, not a best-effort share
• //A circuit that is not shared with the delegate Wi-Fi
• //A second path from a different carrier, ideally entering the building by a different route
• //Static addressing or at least a stable NAT, because some ingest protocols dislike a changing source

Distribution is not your bandwidth problem

If 5,000 people watch your stream, that traffic is served by the platform's CDN from edge nodes near the viewers. None of it passes through the venue.

This matters because it removes a whole category of anxiety. Your venue link does not scale with audience size. A 50-viewer event and a 50,000-viewer event use the same uplink.

What does scale with audience is your CDN bill, which is a budgeting question rather than an engineering one.

What bonded cellular actually buys

Bonding aggregates several mobile connections, usually across different carriers, into one logical link. For event contribution it is close to essential, and not primarily for the bandwidth.

It buys path diversity. The failure you are protecting against is not "the internet is slow", it is "somebody unplugged a switch" or "the venue's single fibre was cut by roadworks". Two entirely separate physical paths is what makes a stream survive that, and cellular is the easiest second path to arrange.

Test it properly: run the event on the backup path during rehearsal. A backup nobody has ever carried live traffic is a hope.

The numbers to put in the plan

For a single-camera 1080p stream with a backup path:

• //Committed venue circuit: 25 Mbps up, dedicated
• //Bonded cellular: three carriers, 20 Mbps aggregate sustained
• //Encoder configuration: 6 Mbps primary, with adaptive fallback to 3 Mbps rather than dropping

For multi-camera or 4K, scale the first two and re-survey — 4K contribution changes the answer materially and should be a deliberate decision rather than a default.

The failure to rehearse

Pull the primary cable during rehearsal, with the stream live to a private endpoint, and watch what happens. Time the failover. If it is not under five seconds and automatic, you have a plan that needs a human to be watching at the exact moment it fails.