| Minimum (kbps)* | Maximum (kbps)* | Recommended* | |
|
Audio 1:1 calls |
limited by network | limited by network | limited by network |
| Conference call | 32 per participant | 160, max. for 5 participants | 160, max. for 5 participants |
| Video 1:1 calls | limited by network | limited by network | limited by network |
| Video conference | 800 per participant |
on desktop 7200, max 9 participants |
on desktop 6400, max 8 participants (downstream) + 1 x 800 (upstream)
|
*All numbers are estimates.
For example
Conference call with 50 participants of which 15 have a camera enabled and example user has the camera enabled:
Upstream
Audio 32 kbit/s + Video 800 kbit/s = 832 kbit/s (roughly 1 Mbit/s upstream should be considered good)
Downstream
A = 5 (capped at 5 max) Audio = 160 kbit/s
V = 8 (current Wire client cannot show more than a grid of 3x3 videos) Video = 6400 kbit/s
Total: Audio + Video = 6560 kbit/s (roughly 7 Mbit/s downstream should be considered good as there is always an overhead to the theoretical values indicated)
1:1 calls
In the 1:1 call use case, there is no predetermined bandwidth set on the media streams. The device itself tries to figure this out using a process called bandwidth estimation. This means that the device ramps up its bitrate until it is announced that the receiving device is losing packets. At this point, it backs off and waits for a report on whether packets are still being lost or not, it repeats this process until no more packets are lost, and it also re-tries to ramp up, after a grace period or detected change in the network.
Conference calls
In conference calls, the bandwidth restrictions are predetermined, and the device is not informed about packet loss. However, in newer versions of the SFT, we implemented a mechanism to request retransmission of lost packets. The bandwidth estimation still does not kick in, and a cap at 800 kbit/s is set on the stream.
With this cap, the device video encoder (VP8) tries to fit the requested resolution and requested frame rate into this maximum restriction. If the device’s upstream network link is of lower quality, it might still suffer from packet loss, resulting in artifacts in the video stream, mostly in the form of either frozen (garbled – on Firefox) pictures or artifacts in the picture when movement happens.
Conclusion
For a good quality audio/video stream in a 1:1 call the Wire client will do its best to keep the quality as high as governed by the current network conditions.
In the case of conference calls with video enabled a minimum upstream of 900kbit/s is required at the time of writing of this document, as for the downstream it depends entirely on the number of video streams requested by the client at any given time, the formula is:
- Audio: A x 32 kbit/s
- Video: V x 800 kbit/s
Where:
- A is the number of active audio streams or a maximum of 5 (loudest).
V is the number of video streams currently requested (displayed) by the client, with a maximum of 9 (if no video is being sent)