Large audiences on a corporate network
Last updated: October 9, 2026
What a large office audience demands
Live and on-demand video reaches viewers as a multi-bitrate HLS stream from the AWS CloudFront CDN, over ordinary HTTPS. Two things about that shape everything else on this page.
Every viewer downloads their own copy. Three hundred people in one building means three hundred separate streams crossing your internet connection.
The player climbs to the best quality the connection will sustain. Left alone, the audience takes as much bandwidth as the link gives them, and then everyone buffers together, including the colleagues who are not watching.
A multi-bitrate stream takes up to 5 Mbps per viewer (see Firewall & VPN configuration ). Three hundred viewers at that maximum is roughly 1.5 Gbps, on a link that also carries mail, file sync and video calls. The rest of this page is about bringing that number down.
Reduce what each viewer takes
The event organiser can do this in the live channel’s Advanced playback settings . For a large office audience:
- Max automatically selectable quality : cap it one step below the top. Most people will not notice on a laptop, and the worst case drops for every viewer.
- Limit quality to player size : turn it on for desktop too when your event page shows the video in a narrow column.
The settings apply to everything on the live channel. To limit one event only, use an event specific live channel.
Reduce what the office takes in total
Capping quality lowers what each viewer takes, but every viewer still fetches their own copy. Peer-to-peer (P2P) delivery changes that. Viewers watching the same stream on the same network share video segments with each other, so the stream crosses your internet connection a few times instead of once per viewer. It works for live streams and for recordings.
P2P is a separately priced add-on, enabled per live channel on request. If the network blocks it, playback falls back to the CDN as normal, so it never puts the event at risk.
Two articles cover it in full:
- Peer-to-peer video delivery , for organisers: what it is, when it helps, and what your organisation needs to do.
- Network requirements for peer-to-peer video delivery , for the network team: the connectivity it needs.
What the network team can do
The domains and ports are in the Firewall & VPN configuration guide. What matters for bandwidth is below.
Split tunnelling for VPN users
Video is the heaviest traffic an event generates. If your VPN routes everything through the corporate network, each remote viewer’s stream travels through your data centre and competes with the office audience on the same link. Configure split tunnelling for the video domains wherever your VPN policy allows it. Viewers on a VPN also often cannot reach each other for peer-to-peer delivery.
Allowlist by domain, not by IP
CloudFront has no fixed set of addresses, so IP-based rules break without warning. Allowlist the domains listed under HLS stream access in the firewall guide. If your policy requires IP rules, the same section links to the CloudFront IP ranges AWS publishes.
Proxies and caching proxies
A proxy that does not decrypt HTTPS cannot cache the video. A proxy that does has to carry every viewer’s stream through one device, which usually moves the bottleneck rather than removing it. Playback URLs can also carry per-viewer access parameters, so a general-purpose cache may not get a hit at all. If you want one copy of the stream shared locally, peer-to-peer delivery is the supported way to get it.
Before the event
-
Work out the number. Viewers per site, multiplied by the per-viewer figure above, against what each site’s connection has spare during working hours. If you have run events with us before, ask support for viewer statistics by ISP and IP address from them. They show how many people actually watched from each site.
-
Test the stream. Viewers watch a delayed HLS stream. Test it with a short test stream to the real office network, with a handful of viewers at roughly the same time of day as the event. If peer-to-peer is enabled, the test also shows how much traffic went peer to peer, and we pass on tuning recommendations before the real event.
-
Test the real-time connection. If the event uses a real-time stream or allows viewers to ask questions with their voice (talkback), run the connection test as well. These use a separate WebRTC connection that the test stream does not cover. Open the connection test page on a machine at the site people will join from. It checks that the network allows the real-time connection and reports its quality. See Testing your connection for what each check means.
Frequently asked questions
Can we limit quality for one event without affecting the others?
Yes. Create an event specific live channel for that event first, then set the limits on it. A shared channel carries its settings into every event that uses it.
What do viewers on a good connection see if we cap the quality?
The capped quality, with no message and no error. People watching from home on a fast line get the same ceiling as everyone else, which is worth weighing if most of your audience is remote and only one site is constrained.
Can people watch over the VPN?
Yes. Without split tunnelling, though, each remote viewer’s stream travels through your corporate connection and competes with the office audience. See Split tunnelling for VPN users .
Getting help
Contact your usual contact person or support_CWC@euronext.com well before the event. Peer-to-peer has to be enabled on your live channel beforehand, quality caps are best decided in advance, and a test stream needs scheduling.