Today we are going to test how many participants it’s possible to place in one video conferencing room, which works with WebRTC by direct peer 2 peer connection.
Just to remind you: usually, platforms like Zoom or Google Hangouts use a video streaming service as a middle man, and every participant connects to the central server. So basically you send your video/audio stream to the server and then the server re-sends it to all other participants.
And it works great for video conferencing when you need to place many users in one room.
But sometimes, there are specific cases, like Telemedicine applications, when you basically need to connect only two-three participants in a chat room. In such a case it’s possible to avoid using a central video streaming server – connect users directly to each other. It’s called the WebRTC Mesh system.
The advantage of this approach is greater security and avoiding costs for the streaming server. Also, some medical regulations like German KVB don’t allow using any type of video streaming server at all. Meaning, WebRTC Mesh peer 2 peer system is the only way to go.
The disadvantage on the other hand is that since there is no server, all the video processing load is done by the participant’s browser. And this load is quite high.
So let’s check the maximum number of users possible to place in one room with WebRTC Mesh peer 2 peer system without getting our computer into flames 🙂
For the testing, we will use our WebRTC based peer 2 peer Mesh system, called Stusan.
We developed it as a barebone system and are now building customer platforms for Telemedicine, Sales calls, Support calls on top of it.
Usually, the system looks like that for 4 users. We are using the best WebCam HD video quality. In this case my Macbook Pro shows a 30% CPU load.
Now let’s add more users, 6 participants, HD video quality – CPU load around 45%. Click on the image to watch a short Youtube clip.
And I would say, 6 participants with HD video is the comfortable maximum. Any users on top – the system starts to lag and stutter.
Obviously high video resolution looks nice but overwhelms the CPU. In the next part, we reduce the video resolution to a minimum that web camera can provide. We have added 9 participants to the room and it worked Ok on my laptop, with around 70% of CPU load. But on the slower computers, it starts to reach 100% CPU load. The right upper guy on a video is clearly lagging 🙂 He is using a Macbook Air. Click on the image below to watch a short Youtube clip.
And as a fun part, some time ago we added 16 users in a room with low video resolution, then our local Wifi Access Point in the office crashed 🙂 Yes, such a peer2peer Mesh approach makes a great impact on the Network. If you have 16 users in a room, every participant sends 15 video/audio streams and receives 15 streams from the other users. You can imagine how big the load is for the Wifi if you do this inside one office.
To summarize: WebRTC peer 2 peer Mesh system works great for one to one calls and for small groups of people. It’s not a silver bullet and should be used in appropriate situations with the upper limit set for the video quality and the number of users in one room.
For a closer look, check a video of our internal testing!
I will be glad to answer all your questions or discuss your ideas, ping me at sz@trembit.com
And it works great for video conferencing when you need to place many users in one room.
But sometimes, there are specific cases, like Telemedicine applications, when you basically need to connect only two-three participants in a chat room. In such a case it’s possible to avoid using a central video streaming server – connect users directly to each other. It’s called the WebRTC Mesh system.
The advantage of this approach is greater security and avoiding costs for the streaming server. Also, some medical regulations like German KVB don’t allow using any type of video streaming server at all. Meaning, WebRTC Mesh peer 2 peer system is the only way to go.
The disadvantage on the other hand is that since there is no server, all the video processing load is done by the participant’s browser. And this load is quite high.
So let’s check the maximum number of users possible to place in one room with WebRTC Mesh peer 2 peer system without getting our computer into flames 🙂
For the testing, we will use our WebRTC based peer 2 peer Mesh system, called Stusan.
We developed it as a barebone system and are now building customer platforms for Telemedicine, Sales calls, Support calls on top of it.
Usually, the system looks like that for 4 users. We are using the best WebCam HD video quality. In this case my Macbook Pro shows a 30% CPU load.
Now let’s add more users, 6 participants, HD video quality – CPU load around 45%. Click on the image to watch a short Youtube clip.
And I would say, 6 participants with HD video is the comfortable maximum. Any users on top – the system starts to lag and stutter.
Obviously high video resolution looks nice but overwhelms the CPU. In the next part, we reduce the video resolution to a minimum that web camera can provide. We have added 9 participants to the room and it worked Ok on my laptop, with around 70% of CPU load. But on the slower computers, it starts to reach 100% CPU load. The right upper guy on a video is clearly lagging 🙂 He is using a Macbook Air. Click on the image below to watch a short Youtube clip.
And as a fun part, some time ago we added 16 users in a room with low video resolution, then our local Wifi Access Point in the office crashed 🙂 Yes, such a peer2peer Mesh approach makes a great impact on the Network. If you have 16 users in a room, every participant sends 15 video/audio streams and receives 15 streams from the other users. You can imagine how big the load is for the Wifi if you do this inside one office.
To summarize: WebRTC peer 2 peer Mesh system works great for one to one calls and for small groups of people. It’s not a silver bullet and should be used in appropriate situations with the upper limit set for the video quality and the number of users in one room.
For a closer look, check a video of our internal testing!
I will be glad to answer all your questions or discuss your ideas, ping me at sz@trembit.com
