←back to thread

Show HN: Zoom Redirector

(github.com)
279 points arkadiyt | 6 comments | 22 Mar 20 22:11 UTC | HN request time: 0.891s | source | bottom
Show context
jwr ◴[23 Mar 20 10:58 UTC] No.22662783[source]▶
I highly recommend using solutions based on WebRTC, which is present in all modern browsers and is really good (see https://www.youtube.com/watch?v=WFil-ZPE0-g for a comparison with Zoom).

Whereby (formerly appear.in) https://whereby.com/ has a really nice and simple system. No more jumping through a dozen hoops, no more installing software with glaring security holes and borderline malware behavior (looking at you, Zoom).

replies(2): >>22662842 #>>22667048 #
1. Quanttek ◴[23 Mar 20 11:07 UTC] No.22662842[source]▶
How does WebRTC compare when you have a lot of callers (e.g. 20 people in a call)? From my understanding, it is p2p, so the network throughput required would be a lot higher, correct?
replies(4): >>22662904 #>>22663835 #>>22674875 #>>22683334 #
2. jwr ◴[23 Mar 20 11:18 UTC] No.22662904[source]▶
TBH, I have no idea, I have done calls with up to 8 people only. I would be interested to know myself. Whereby seems to support up to 12 video streams, with the rest being audio-only.
replies(1): >>22663010 #
3. DyslexicAtheist ◴[23 Mar 20 11:37 UTC] No.22663010[source]▶
we've been using jit.si in 2016 which worked well but it might be overloaded today idk. we hit some bottlenecks when trying to scale up and improved the situation by running our own jitsi instance on a DO droplet but that too would not scale to a large audience. I think that if you have more than 10 participants in the meeting then you have anyway other problems (the same issues when you have too many people in a f2f meeting).

from a technical pov I still wonder if running jitsi (or another similar solution) on dedicated hardware which is better tailored to a GPU intensive operation. This could then be easily deployed in-house (with all the benefits: full control and eliminating a lot of attack vectors). Seems like a cool problem to solve while in corona quarantine.

4. chupasaurus ◴[23 Mar 20 13:21 UTC] No.22663835[source]▶
IIRC Skype back when it was p2p used the first participant as a host with full resync if it went down.
5. cloverich ◴[24 Mar 20 14:18 UTC] No.22674875[source]▶
Yes p2p, so to support higher numbers of people you'd need either a server somewhere doing compositing or selective forwarding (etc). I think a smart front-end client could do selective forwarding but would be tricky to get right (e.g. to consistently detect and forward the speaker).

EDIT: I meant to include, WebRTC itself does not prohibit such things, so the point was for small stuff it works w/ minimal setup, dumb client, and for bigger stuff it would still work, but would need more robust supporting code.

6. sigwinch28 ◴[25 Mar 20 10:33 UTC] No.22683334[source]▶
The default installs of Jitsi Meet use Jitsi videobridge to avoid p2p for calls of >2 participants.

For <=2 people, p2p WebRTC is used (though a STUN server might be needed to traverse NATs for each person [0]).

For >2 people, the Jitsi Videobridge is used instead of p2p [1]: it takes in all media streams from all clients (possibly even in different resolutions) and selectively forwards them to clients based on bandwidth [2]

[0]: https://en.wikipedia.org/wiki/STUN [1]: https://jitsi.org/jitsi-videobridge/ [2]: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/s...