-
-
Notifications
You must be signed in to change notification settings - Fork 67
Video SFU / Conferencing #66
Comments
In addition these might also be possible candidates: |
Some performance observations: https://webrtchacks.com/sfu-load-testing/ Another candidate seems to be medooze. Looks like there is an e2e encryted version under way https://github.com/medooze/sfu In general privacy considerations should be addressed. See also #68 |
You could consider using multiparty meeting that is based on mediasoup. It scales better than jitsi thank to VP9 codec which reduces up to 40% the bandwidth requirements. |
Awesome, thanks @erotavlas-turbo for the details. Indeed mediasoup looks great. I removed the Jitsi feature anyway for now to strengthen the privacy and server-less features. PERC seems to be some time away from becoming a real world option with broad support in modern browsers. BTW, to experiment a bit more with multi user WebRTC scenarios I created a spin off that focuses on the video chat feature: https://brie.fi/ng |
Maybe you are interesting at this: jitsi is working on e2ee conference. |
Absolutely! Thanks for sharing the info @erotavlas-turbo |
Finally, jitsi is actively working on VP9 support. |
While developing the video chat solution in peer.school it turned out that multi-peer streaming is not practicable for a large number of participants due to bandwidth and performance (see #63). An SFU (Selective Forwarding Unit) was required that would receive participants video and audio streams and forward those the the participants, reducing the numbers of connections a client has to handle.
The current implementation uses Jitsi for this purpose: https://github.com/jitsi/lib-jitsi-meet
Other solutions might also be worth considering, like mediasoup:
This should also fix related issues like #65 #34
The text was updated successfully, but these errors were encountered: