4 ms·

Jitsi been such garbage to work with. Their own self published numbers of the participants in an average video call is 3. Which is a piece of cake for p2p WebRT

Jitsi been such garbage to work with. Their own self published numbers of the participants in an average video call is 3. Which is a piece of cake for p2p WebRTC calling which scales without a media server upto 9-10 participants on modern hardware and network. For extremely high users in an effective webinar you'd anyway need HLS based streaming so what even is the point of a media server at that time

chabad360 3y ago
The benefit of using jitsi is that you don't have to build the stack yourself.
- v3ss0n 3y ago
  https://github.com/livekit/ https://github.com/livekit/ It dosen't limit number of P2P participants.
- villgax 3y ago
  The benefits of properly using WebRTC is you don't need a media-server
  - russ 3y ago
    It really depends on the use case. In vanilla WebRTC, all media is transmitted directly between peers. In practice, this doesn’t scale beyond 5-10 users in a session. Most home internet connections can’t sustain that amount of upstream bandwidth.
manishsharan 3y ago
I am curious .. how would you convert an inbound webrtc stream (from the presenter) to HLS for a broadcast to the viewers? Wouldn't the lag make it unusable?
- villgax 3y ago
  https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stream/ https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stre... It's just a matter of pipelines with ffmpeg
- russ 3y ago
  You can do that with LiveKit Egress: https://github.com/livekit/egress https://github.com/livekit/egress
agumonkey 3y ago
What's extremely high ? we've tried it at work for around 30 people, with 2-3 main speakers, sometimes more, and it was as lean as things could be. No lag, no .. nothing. I don't know how they set it up thought, self hosted most probably, maybe that's the only way to get good performance.
andrewaylett 3y ago
Averages aren't necessarily much use here, as there are a lot more opportunities for small video calls than for large ones. If a team of seven has one team meeting and each non-manager has a one-to-one with the manager, the average number of people in a call is ~three. But they're still not going to use a system that can't cope with seven in a call. And they won't have any calls with more than seven participants even if the software can scale to dozens. (It's also worth noting that Zoom have shown that it's possible to develop "video conferencing" UX than scales to hundreds of participants. I have no idea whether they do this by naively scaling up or by radically changing the way the conference works past a threshold number of participants, but as a participant I don't care)
- moritzwarhier 3y ago
  I don't know what differentiated Zoom from its competitors, but a self-administered server will always be harder than using SaaS for stuff like video calls / WebRTC. WebEx seems to work fine too for huge calls, although I use the native client for it. At a previous job, I once helped a tiny bit with setting up and configuring the company's Jitsi instance (wasn't the admin though). As far as I can tell, the differences mainly affect non-P2P mode, which the server will enable above some bandwidth or participant number threshold. Another thing all these WebRTC clients have to achieve reliably is dealing with different NAT setups and firewalls (one piece of this seems to be achieved with technologies STUN and TURN). I guess video conferencing is at least as complex as implementing real-time multiplayer games over the internet. Edit: Just read up that WebEx predates WebRTC and uses it only for interop with other tools. Zoom uses a custom technology stack as well as far as I know (I have no idea if it involves WebRTC). So maybe WebRTC really is hard to scale up large numbers of participants. Haven't heard much good about Teams in this regard either (which uses WebRTC AFAIK)
  - russ 3y ago
    Zoom does use a custom protocol. This is why it doesn’t work nearly as well when you take a call in the browser client. Not because WebRTC isn’t up to the task, but because Zoom hasn’t invested in it. Ignoring costs, while having someone host infra for you will always be easier than managing it yourself, I think we’ve really improved the DX of hosting your own WebRTC infra with LiveKit: https://github.com/livekit/livekit https://github.com/livekit/livekit
russ 3y ago
HLS is a client-driven protocol, so it has high-scale but variable latency. You could build a mostly one-way webinar experience using it, but definitely not a conference call experience. The primary issue with traditional WebRTC media servers and services is they didn’t horizontally scale. That’s changed recently. You can get pretty high numbers of users in a single WebRTC session now.
saghul 3y ago
Care to elaborate? Jitsi Meet might not be right answer to all use cases, but IMHO (disclaimer, I work on Jitsi at 8x8) it strikes a good balance. Many think they can go P2P, but browsers implement one bandwidth estimator per PeerConnection, so that begins to hurt quickly in practice. In addition, sending multiple HD streams to serveal participants it's going to hurt the sender, but an SFU helps with that. There are many more reasons, this is just scratching the surface.

chabad360 3y ago

The benefit of using jitsi is that you don't have to build the stack yourself.

v3ss0n 3y ago
https://github.com/livekit/ https://github.com/livekit/ It dosen't limit number of P2P participants.
villgax 3y ago
The benefits of properly using WebRTC is you don't need a media-server
- russ 3y ago
  It really depends on the use case. In vanilla WebRTC, all media is transmitted directly between peers. In practice, this doesn’t scale beyond 5-10 users in a session. Most home internet connections can’t sustain that amount of upstream bandwidth.

manishsharan 3y ago

I am curious .. how would you convert an inbound webrtc stream (from the presenter) to HLS for a broadcast to the viewers? Wouldn't the lag make it unusable?

villgax 3y ago
https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stream/ https://blog.cloudflare.com/webrtc-whip-whep-cloudflare-stre... It's just a matter of pipelines with ffmpeg
russ 3y ago
You can do that with LiveKit Egress: https://github.com/livekit/egress https://github.com/livekit/egress

agumonkey 3y ago

What's extremely high ? we've tried it at work for around 30 people, with 2-3 main speakers, sometimes more, and it was as lean as things could be. No lag, no .. nothing. I don't know how they set it up thought, self hosted most probably, maybe that's the only way to get good performance.

andrewaylett 3y ago

Averages aren't necessarily much use here, as there are a lot more opportunities for small video calls than for large ones. If a team of seven has one team meeting and each non-manager has a one-to-one with the manager, the average number of people in a call is ~three. But they're still not going to use a system that can't cope with seven in a call. And they won't have any calls with more than seven participants even if the software can scale to dozens. (It's also worth noting that Zoom have shown that it's possible to develop "video conferencing" UX than scales to hundreds of participants. I have no idea whether they do this by naively scaling up or by radically changing the way the conference works past a threshold number of participants, but as a participant I don't care)

moritzwarhier 3y ago
I don't know what differentiated Zoom from its competitors, but a self-administered server will always be harder than using SaaS for stuff like video calls / WebRTC. WebEx seems to work fine too for huge calls, although I use the native client for it. At a previous job, I once helped a tiny bit with setting up and configuring the company's Jitsi instance (wasn't the admin though). As far as I can tell, the differences mainly affect non-P2P mode, which the server will enable above some bandwidth or participant number threshold. Another thing all these WebRTC clients have to achieve reliably is dealing with different NAT setups and firewalls (one piece of this seems to be achieved with technologies STUN and TURN). I guess video conferencing is at least as complex as implementing real-time multiplayer games over the internet. Edit: Just read up that WebEx predates WebRTC and uses it only for interop with other tools. Zoom uses a custom technology stack as well as far as I know (I have no idea if it involves WebRTC). So maybe WebRTC really is hard to scale up large numbers of participants. Haven't heard much good about Teams in this regard either (which uses WebRTC AFAIK)
- russ 3y ago
  Zoom does use a custom protocol. This is why it doesn’t work nearly as well when you take a call in the browser client. Not because WebRTC isn’t up to the task, but because Zoom hasn’t invested in it. Ignoring costs, while having someone host infra for you will always be easier than managing it yourself, I think we’ve really improved the DX of hosting your own WebRTC infra with LiveKit: https://github.com/livekit/livekit https://github.com/livekit/livekit

russ 3y ago

HLS is a client-driven protocol, so it has high-scale but variable latency. You could build a mostly one-way webinar experience using it, but definitely not a conference call experience. The primary issue with traditional WebRTC media servers and services is they didn’t horizontally scale. That’s changed recently. You can get pretty high numbers of users in a single WebRTC session now.

saghul 3y ago

Care to elaborate? Jitsi Meet might not be right answer to all use cases, but IMHO (disclaimer, I work on Jitsi at 8x8) it strikes a good balance. Many think they can go P2P, but browsers implement one bandwidth estimator per PeerConnection, so that begins to hurt quickly in practice. In addition, sending multiple HD streams to serveal participants it's going to hurt the sender, but an SFU helps with that. There are many more reasons, this is just scratching the surface.