Different platforms and systems have different recommendations for bandwidth required. Some of the common ones we use are detailed below.
The Basics
When discussing connection speeds with venues or clients there are two important things to remember.
When planning streams from an event to YouTube or similar, the ‘speed’ we are interested in is upload. We are sending video from site up to the internet. They can have the fastest download ever but if the upload isn’t available the stream won’t make it. You will hear phrases like ‘300 down, 70 up’ or ‘80 megabit synchronous’. The first means there is 300Mbps (megabits per second) download speed but only 70Mbps upload speed. The second means that the upload and download speeds are equal, so 80Mbps up and 80Mbps down in this example. For conference solutions, video is streaming in both directions so equal bandwidth needs to be available.
Secondly, the bandwidth should be uncontended. This means that the bandwidth is protected and dedicated to us to stream with. What you don’t want to find is that during rehearsals your connections speeds are fine, only to discover that the public WiFi shares the same connection and bandwidth. As the venue fills up with people and more importantly their devices, your share of the available bandwidth gets less and less until there isn’t enough to stream.
Testing Speeds
There are countless speed testing sites available, but for the benefit of this example we are going to look at CT’s speed test site which is powered by Ookla. speed.ctlive.events
The simple interface looks like the screen shot below. If you click ‘GO’ the site will perform a test starting with the download, moving on to the upload and finally giving you an overall reading of the speed. It is important to note that this speed is to the nearest server which might be very close to you, giving you the best possible speed. What we are more interested in is where we are sending the stream to.
In most cases the big CDNs (content distribution networks) like YouTube and Facebook have many ingest points and your stream will be automatically pointed to the closest one. However, if we are streaming to specific ingest point (a client’s own internal streaming server, a point to point link etc) we want to test the speed to their location, not just to the internet.
On the speed.ctlive.events page is an option to Change Server. You can click on this and search for a location closer to your ingest point. The example below shows two speed tests for an event where we are sending a stream directly from CT London to CT San Francisco.
The example of the left just shows a test on the default website so we are actually testing to a site in London. On the right is an example where the server has been changed to one more local to San Francisco. Although still fast enough to send a decent stream, much more varied.
Bitrates
When an encoder is set up it is configured to compress the video is receives to a target bitrate measured in Mbps (megabits per second). The higher the bitrate, the better the video quality but the more bandwidth you need from the venue. The recommendations below are what the platforms suggest you send them for the best viewers experience. You can send less if the upload speed isn’t available but the quality will be lower.
Backup Streams
Backing up streams is not the seamless, immediate failover that most clients are looking for, and a lot of platforms don’t even have the option for it. YouTube is the obvious one that does support it, however their failover can take up to 10 seconds and moreover it is likely that your backup stream is going over the same internet connection at the venue so if the connection is the problem, a backup stream is not going to help. Facebook, Wowza, Twitch and Vimeo do not have a provision for a backup stream, the best you can do is a second encoder as a ‘warm spare’ to manually switch over to if the primary encoder fails.
Recommendation NEP @ Home
The NEP@ Home system can handle anything between 1mb and 30mbps depending on available connectivity.
Recommendation for YouTube
Backup stream supported, ingest location dynamically selected at time of streaming to allow load balancing on YouTubes side. Rule of thumb, speed test to the nearest capital city.
720p@50 requires up to 4Mbps
1080p@50 requires up to 6Mbps
2160@30fps requires up to 35Mbps
2160@60fps requires up to 51Mbps
Recommendations for Facebook
Ingest location dynamically selected at time of streaming to allow load balancing on Facebooks side. Rule of thumb, speed test to the nearest capital city. Facebook only supports the streaming protocol RTMPS which few hardware encoders support. If using hardware encoders, check compatibility.
Maximum resolution of 1080p@60 is supported with a maximum bitrate of 4Mbps
Recommendations for Twitch
Manually choose the ingest point from the list of available points of presence at https://stream.twitch.tv/ingests/
Maximum recommended bitrate of 6Mbps regardless of resolution.
Recommendations for Zoom
1:1 video calling
600kbps (up/down) for high quality video
1.2 Mbps (up/down) for 720p HD video
1.8 Mbps (up/down) for 1080p HD video
For group video calling
800kbps/1.0Mbps (up/down) for high quality video
For gallery view and/or 720p HD video: 1.5Mbps/1.5Mbps (up/down)
Gallery view of 1080p HD video requires 3Mbps (up/down)
Other Functions
For screen sharing only (no video thumbnail): 50-75kbps
For screen sharing with video thumbnail: 50-150kbps
For audio VoiP: 60-80kbps
For Zoom Phone: 60-100kbps
Recommendations for Skype
| Call type | Minimum download / upload speed | Recommended download / upload speed |
| Calling | 30kbps / 30kbps | 100kbps / 100kbps |
| Video calling / Screen sharing | 128kbps / 128kbps | 300kbps / 300kbps |
| Video calling (high-quality) | 400kbps / 400kbps | 500kbps / 500kbps |
| Video calling (HD) | 1.2Mbps / 1.2Mbps | 1.5Mbps / 1.5Mbps |
| Group video (3 people) | 512kbps / 128kbps | 2Mbps / 512kbps |
| Group video (5 people) | 2Mbps / 128kbps | 4Mbps / 512kbps |
| Group video (7+ people) | 4Mbps / 128kbps | 8Mbps / 512kbps |
Recommendations for Microsoft Teams
| Bandwidth(up/down) | Scenarios |
| 30 kbps | Peer-to-peer audio calling |
| 130 kbps | Peer-to-peer audio calling and screen sharing |
| 500 kbps | Peer-to-peer quality video calling 360p at 30fps |
| 1.2 Mbps | Peer-to-peer HD quality video calling with resolution of HD 720p at 30fps |
| 1.5 Mbps | Peer-to-peer HD quality video calling with resolution of HD 1080p at 30fps |
| 500kbps/1Mbps | Group Video calling |
| 1Mbps/2Mbps | HD Group video calling (540p videos on 1080p screen) |
Leave a Reply