How to live stream an event: bitrate, encoder, delivery

Sizing: bitrate times concurrent viewers

Delivery capacity is the stream's bitrate multiplied by the peak number of concurrent viewers. Total attendance does not matter; the minute when the most people are watching does. The volume moved is the same rate held over the length of the event. The table below is our own arithmetic, with 1 Gbps = 1,000 Mbps and 1 TB = 1,000,000 MB.

One viewer at 4.5 Mbps pulls about 2 GB an hour (4.5 Mbps x 3,600 s / 8). Multiply by viewers and hours and the transfer column follows. Audio adds a little on top of the video rate.

Where a single server's port runs out

A single streaming server is capped by its switch port. Our dedicated streaming server page works the number: with every viewer on a 4.5 Mbps 1080p rendition and a fifth of the port held back, a 1 Gbps port carries 177 viewers at once, 10 Gbps carries 1,777 and 100 Gbps carries 17,777. Past the first few hundred people the port, not the processor, is the limit.

The second limit is distance. One machine sits in one city, so a viewer on another continent fetches every segment across the ocean. A CDN fixes both at once: viewers are spread over several cities, and each city fetches a segment from the origin once, then serves it to everyone it carries. A whole server is still the right tool for a regular audience of a few hundred, or when you run your own engine; for one night at ten times your normal audience, it is the wrong one.

Choosing the picture: Apple's ladder, one rung

Apple's HLS authoring spec publishes an example H.264 ladder for 16:9 video. A few of its rungs, in average kbit/s:

The spec calls this one possible set, not a requirement, while separately requiring several bit rates so a player can step down on a weak connection, with the 2,000 kbit/s variant as the default for Wi-Fi delivery on iOS and 730 kbit/s for cellular. An event on our CDN carries the quality you choose in the event configurator, which is meant to match your encoder's output bitrate: every viewer receives that stream. Pick the rung your weakest important viewer can sustain, not the one that looks best on the venue monitor. The embedded player plays up to 1080p, so sending more than 1080p buys nothing.

Encoder settings at the venue

Any RTMP encoder will do: OBS Studio, vMix and Wirecast in software, or a dedicated box such as the Teradek, Epiphan Pearl and Cerevo LiveShell boxes on our hardware encoders page. In OBS the destination goes under Settings, Stream, with Service set to Custom. The settings that matter on the night:

• Bitrate: measure the venue's upload and start at no more than 75% of it, the starting point the OBS connection troubleshooting guide gives.
• Keyframes: every 2 seconds. Apple's spec says IDR frames should be present every two seconds, and every video segment must start with one.
• Cable: OBS recommends a wired connection for streaming. Venue Wi-Fi shared with the audience is the usual cause of dropped frames.
• Congestion: OBS ships a beta setting in its Advanced network settings, "Dynamically change bitrate to manage congestion". It trades picture quality for fewer dropped frames, and OBS is clear that it does not cure the cause.
• Frame rate: if the machine reports encoding overload at 60 fps, OBS's performance guide suggests dropping to 30.

For RTMP the dashboard prints the server, rtmp://ingest.video.serverroom.net/ followed by the channel's name, plus a stream name, username and password. That hostname answers with the nearest of our cities, so the stream enters our network close to the venue and rides our own links to the channel's server in New York or Bucharest.

SRT when the venue's line is unreliable

SRT runs over UDP and resends lost packets inside a latency window the two ends agree on: per the SRT documentation, the receiver buffers at least that long, the default is 120 ms, and a connection settles on whichever of the two ends asks for more. On a stadium's shared uplink or a long international hop, that is where RTMP over TCP stalls and SRT holds the picture. The dashboard prints a dedicated SRT port and passphrase for every channel. In OBS the whole connection goes in the Server field as one URL, the Stream Key stays empty, and options are added as query parameters:

srt://HOST:PORT?passphrase=YOUR_PASSPHRASE&latency=1000000

OBS takes latency in microseconds: 1000000 is one second, and its SRT guide advises at least 2.5 times the round-trip time from encoder to ingest. The passphrase sits in plain text in the OBS profile, so keep that machine to the crew. Our SRT streaming server page covers the protocol in depth.

Latency: what HLS segments cost

HLS delay comes mostly from segment length. Apple's spec sets the target duration at 6 seconds and asks for at least six segments in a live playlist, and the HLS protocol (RFC 8216) tells players not to start closer than three target durations from the end of the playlist. A viewer therefore sits many seconds behind the room, which is fine for a keynote or a match and awkward only when the online audience must react in real time, such as a live Q&A or voting.

Apple's Low-Latency HLS cuts this with partial segments, recommending a one-second part target. It needs support at every hop, so check the delivery path before planning a show around it. For a one-off event, accept the ordinary delay and take questions through chat or a moderator.

Running the night on our CDN

1. Size and order. In the live event streaming configurator choose the days, the hours, the peak audience (100, 500, 1,000, 5,000, 10,000 or 50,000 viewers) and the stream quality. The price shows before you pay.
2. Wait for the channel. It is built on the CDN automatically once payment clears, with the encoder settings in the dashboard and the welcome email. Order a few days ahead.
3. Rehearse. The channel works as soon as it exists. Send a test from the venue the day before and watch it through the player, the way the audience will.
4. Connect the venue. RTMP, SRT or WebRTC (WHIP) into the nearest city; SRT if the line is shaky.
5. Restream if you want. Add YouTube, Facebook, Twitch or any RTMP address, up to 5 at once, from the Live tab without a second encoder; our multistreaming page covers the upload arithmetic of doing that yourself.
6. Watch and export. The Live tab lists each viewer with country and player; export the list as a spreadsheet before the night ends.

Each viewer is served by whichever city is closest, and the five run from San Francisco in the west to Bucharest in the east. A city that stops answering drops out within 60-120 seconds and the next nearest takes its viewers. The video CDN page lists which regions each city serves.

Limits to plan around

• The event configurator stops at 50,000 concurrent viewers. Above that, ask in the live chat and the event is sized with you.
• Viewer limits are enforced on the channel, so the audience you order is a hard ceiling, not an estimate.
• One quality per event: every viewer receives the stream you send, so a sharper picture for a bigger crowd needs more capacity.
• If big events come every month, Platinum has event mode built in, 10 channels and 25,000 viewers per channel, with no separate event order.