Is this different from or better than Jitsi Meet? Not intending to criticize the effort, just curious if I should switch my goto choice of video conferencing software.<p><a href="https://meet.jit.si/" rel="nofollow">https://meet.jit.si/</a>
Another fully featured group video chat: <a href="https://talky.io" rel="nofollow">https://talky.io</a><p>It's based on this open source app <a href="https://github.com/simplewebrtc/simplewebrtc-talky-sample-app" rel="nofollow">https://github.com/simplewebrtc/simplewebrtc-talky-sample-ap...</a><p>They also run <a href="https://www.simplewebrtc.com" rel="nofollow">https://www.simplewebrtc.com</a> which is an SDK for building custom WebRTC apps. They also provide TURN and SFU servers.
Is this hosted anywhere?<p>I created <a href="https://omen.tv/" rel="nofollow">https://omen.tv/</a> just last weekend. Similar in that it's powered by WebRTC, but it's designed for casting your screen (e.g. Jackbox Games) to other people's TVs.<p>My greatest annoyances with WebRTC were:<p>1. WebRTC <i>requires</i> a STUN server, and despite the spec initially supporting default ICE servers, it has since been pulled out into an extension because browser vendors don't want to provide servers[1]. There are free STUN servers (Google etc.) but...<p>2. Double NAT clients. STUN is inevitably going to discover double NAT clients. The <i>only</i> way to connect these clients is through a proxy. Specifically a TURN server. Unlike STUN servers, these are not light-weight, and I can totally understand why browser vendors don't offer them by default. So inevitably any WebRTC use still requires a self-hosted TURN server.<p>3. Inconsistent access to streams across browsers. In particular the getDisplayMedia[2] API provides poor availability of the audio stream. Courtesy of Apple doing Apple things, I don't believe it's even possible to implement this API on macOS as there's no audio loopback device. I worked around this for my use-case by installing BlackHole[3] (which is great software!) However, the loopback device appears as an input e.g. like a microphone, so isn't technically the display audio.<p>For this all to be smooth I think all these pain points need to be addressed.<p>Issue 1 and 2 require NAT to be kicked to the curb, come on IPv6! Issue 3, requires Apple to expose a loopback device <i>and</i> browsers to implement support. These aren't insurmountable issues, but they're unfortunately out of our hands as day-to-day devs.<p>[1] <a href="https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/getDefaultIceServers" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConn...</a><p>[2] <a href="https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/MediaDevice...</a><p>[3] <a href="https://github.com/ExistentialAudio/BlackHole" rel="nofollow">https://github.com/ExistentialAudio/BlackHole</a>
The JS code is under 500 lines so this is at least simple and auditable.<p>I didn't see anything about encryption based on a cursory read. Does WebRTC have some built in or is this unencrypted?
Amazing! I think this is the better open-source alternative to Google Meet and Zoom. Of course, this may not be filled with all the features offered by them, but this is more than enough for meeting 6-8 people at a time.
Is there a video call app with screen sharing that doesn't use WebRTC?<p>I often host online lectures and with screen sharing, it always uses up 100% of my CPU resources.
>>> quality of the call is inversely proportional to the number of people on the cal<p>Interesting experiment would be to run locally on high speed LAN with LOTS of participants. Whats the limit to what the browser can handle?<p>Thanks for building, vasanthv ;)
Is this pretty similar to zipcall.io? I've used it a few times and was surprised with how well it worked for video calls and screen sharing.<p>Only problem I had with it was one client that couldn't get his mic working. I'm assuming it was a browser permissions issue but I called him on Signal instead rather than trying to track it down remotely.
WebRTC is amazing, until you start getting users on iPads. The complaints of the Firefox users are easy to ignore (there are so few of them, after all), but the iPad users are too numerous (especially within my company).
here's a similar webrtc app, but free of node.js dependency
<a href="https://ba.net/screen-share-party" rel="nofollow">https://ba.net/screen-share-party</a>
To share just one screen (mostly for my mom and me) I created <a href="https://screenshare.43z.one/" rel="nofollow">https://screenshare.43z.one/</a> in just a few lines of client side js.
Nice! The WebRTC samples tend to be a bit convoluted. This sample project is a great demonstration of simplicity. Going to use this for some data channel work.
Stop giving away great software for free. Sell it! :)<p>(P.S:: Didn't check out the source code. It's just a general sentiment of mine lately.)