Network Requirements for Live Streaming

Live streaming inverts how we normally judge a connection. All day long we watch download speed: how fast pages open, how smoothly video plays. Live streaming uses none of that. It uses upload, the smallest part of a connection, the least tested, and the least likely to be printed large in a plan advert.

This applies equally to live selling, streamed services, online classes, and events broadcast from a venue.

Sizing it

Rough figures for one stream:

• 720p about 3 Mbps upload.
• 1080p about 6 Mbps upload.
• 1080p at 60 frames about 9 Mbps upload.

Then the rule that separates a smooth stream from a stuttering one: provision double. A 1080p stream belongs on a path with at least 12 Mbps of upload.

That isn't excess caution. A path running near capacity has no room to absorb bursts, and streams send data in waves rather than evenly. When a wave exceeds capacity, packets queue and then drop, and that's what viewers see as a broken picture. The distinction between speed, delay, and loss is in bandwidth, latency, and throughput.

Don't forget everyone else on the same connection. One 1080p stream plus five people on their phones already approaches the limit of many consumer plans.

Why upload is so small

Most consumer plans are asymmetric: large download, small upload. A 100 Mbps plan often provides only 10 or 20 Mbps up, and that's what decides whether you can stream 1080p at all. The technical reasons are in why upload is slower than download.

So when choosing a plan for this, the number to chase isn't the one printed largest. Ask specifically about upload, and if a symmetric plan is available, that's the right one even with a smaller download figure (choosing a business plan).

Cable, not Wi-Fi

The most broken rule and the cheapest to follow. Wi-Fi works well until one brief disturbance: a neighbour switching on something in the same channel, someone walking through the signal path, a device hopping access points. In ordinary use, half a second of disruption goes unnoticed. In a live broadcast, every viewer sees it and it can't be retried.

Put the streaming device on cable (choosing LAN cable). If that's genuinely impossible, move close to the router, use 5 GHz, and make sure nothing else is downloading heavily during the broadcast (setting bandwidth priority).

Test before the event, not during it

An ordinary speed test isn't enough, because it measures a moment while a stream runs for hours. Three more useful checks:

• A private test broadcast of 20 to 30 minutes at the same hour as the real event. It's the only test that genuinely represents the conditions. The hour matters, because many networks slow at particular times (slow internet at certain hours).
• A continuous ping to one address during the test broadcast, watching for spikes or lost packets. How, in using ping and traceroute.
• Check your encoder's own statistics. Nearly all report frames dropped due to network, and that figure is more honest than any speed test.

Record the results. If you ever need to raise it with your provider, numbers from a test broadcast carry far more weight than a description of the picture breaking up (customer rights when internet is slow).

Streaming from a venue

Broadcasting from somewhere that isn't yours, such as an event hall or hired room, brings its own problems. Guest Wi-Fi there is usually rate-limited and often blocks the ports encoders use, so the stream won't connect even though the internet works. The reason is explained in ports and protocols worth knowing.

So for a venue broadcast, the sensible order is:

• Ask for a dedicated line from the venue rather than the guest Wi-Fi everyone else is using. A single cabled port is best.
• Bring your own cellular connection as primary or backup, and test its signal at the exact spot you'll broadcast from, not in the lobby (choosing a MiFi or 4G router).
• Consider two different carriers if the event matters. Signal strength between carriers at the same point often differs sharply, and in a full room tower capacity becomes the real limit (venue Wi-Fi capacity).

Devices that bond several connections do exist, and for venue broadcasts they're useful. But bonding is not a substitute for testing: two poor paths still produce a poor stream.

A plan for when it drops

The stream will fail at some point, and the only difference between an event that continues and one that collapses is preparation:

• Record locally while streaming. Nearly every encoder can, and it rescues an event whose broadcast failed.
• Have a tested second connection, not one first tried when the problem appears (backup internet for businesses).
• A small UPS for the router and encoder. A one-second power flicker costs several minutes of broadcast, because everything has to reconnect (a UPS for your router).
• Drop the resolution early. An unbroken 720p stream always beats a stuttering 1080p one, and that decision is easier before the event than during it.

In short

Size it from upload rather than download, and provision double what the stream needs. Cable the streaming device. Run a half-hour test broadcast at the same hour as the event, and write the numbers down. Always record locally. Those four cover nearly every stream failure that actually happens.

Frequently asked questions