some more updates

1 files changed, 13 insertions, 3 deletions

diff --git a/README.md b/README.md
index 9a9d0a0e0..9152fc39e 100644
--- a/README.md
+++ b/README.md
@@ -37,9 +37,19 @@ Here's a short [video](https://youtu.be/KdTsWIy4eN0) on how it's done.
 
 ## Scalability 
 
-Talk works peer to peer, that is, each participant sends an end-to-end encrypted stream to each other participant and receives one stream per other participant. This grows bandwidth usage with the number of participants. As most users are on an asymetric local internet connection, the sending bandwidth often becomes the bottleneck. A typical Nextcloud Talk instance can handle a few dozen calls, but each call can have only 6-10 participants depending on the participants' bandwidth.
+Talk works peer to peer, that is, each participant sends an end-to-end encrypted stream to each other participant and receives one stream per other participant. This grows bandwidth usage with the number of participants. As most users are on an asymetric local internet connection, the sending bandwidth often becomes the bottleneck. A typical Nextcloud Talk instance can handle a few dozen calls, but each call can have only 4-6 participants with video depending on the participants' bandwidth. Without video, more is possible.
 
-To limit bandwidth usage, participants can keep video disabled. Once a video stream is enabled it can currently not be disabled, even a muted or disabled video stream is being send out. This is due to the technical implementation details of WebRTC which is used by Talk. However, Talk remembers the state of audio and video. This means that disabling video, leaving the call and joining again will drop the bandwidth use to audio only (about 50 kbit/sec). This is about 1/20th of the bandwidth of video (1 mbit/sec), so when all participants are on a fast network, a call with 20 people without video could be doable.
+A single video stream currently uses about 1 mb/sec and the total required bandwidth can be calculated as follows:
+
+```
+1 mb/s * (participants - 1)
+```
+
+![](https://nextcloud.com/wp-content/themes/next/assets/img/features/HPB-P2P.svg.png)
+
+This means that in a call with 5 participants, each has to send and receive about 4 mbit/sec. Given the asymetric nature of most typical broadband connections, it is sending video that quickly becomes the bottleneck.
+
+To limit bandwidth usage, participants can keep video disabled. Once a video stream is enabled it can currently not be disabled, even a muted or disabled video stream is being send out. This is currently a technical limitation. However, Talk remembers the state of audio and video. This means that disabling video, leaving the call and joining again will drop the bandwidth use to audio only (about 50 kbit/sec). This is about 1/20th of the bandwidth of video, so when all participants are on a fast network, a call with 20 people without video could be doable.
 
 Such a call does create a high load on the members' browsers and on the server as it handles signaling. This, for example, has consequences also for the devices that support calls. Mobile device browsers will sooner run out of compute capacity and cause issues to the call. While we continously work to optimize Talk for performance, there is still work to be done so it is not unlikely that the bottleneck will be there for the time being. We very much welcome help in optimization of calls!
 
@@ -50,7 +60,7 @@ To make sure a call can sustain the largest number of participants, make sure th
 * each participant has a fast enough system (desktop/laptop browser, mobile device browsers will not do) or uses the Android/iOS app. Best use a desktop browser like Firefox or Chrome. The WebRTC implementation in other browsers is often sub-par.
 * each participant has video disabled **from the start** - that means, if video is on when you start the call, disable it, exit the call and join again to ensure you are not sending 1 mbit/sec of blank screen
 
-With this setup, 20 users is usually doable. Feedback on this is welcome!
+With this setup, 20 users should be doable in a typical setup.
 
 ### Scaling beyond 5-20 users in a call