Zipcall.io – Free browser-based video calling(github.com)
github.com
Zipcall.io – Free browser-based video calling
https://github.com/ianramzy/decentralized-video-chat
35 comments
Hey, If it's using WebRTC built into the browser like every other web-based video calling app – how is it "unmatched" exactly?
Many/most WebRTC apps don't do p2p, but rely on a bunch of stuff happening in server side. There are also a lot of ways to set up webrtc in the browser affecting quality.
Yea, gonna call BS on that. P2P is significantly easier to architect than an SFU/MCU.
On the site it says "Breakthrough peer to peer WebRTC technology" and the title claims "no latency".
Could you elaborate what makes this different from normal P2P WebRTC without a SFU? Do you feel that the claim of "no latency" is even possible/reasonable regardless of the tech involved?
Could you elaborate what makes this different from normal P2P WebRTC without a SFU? Do you feel that the claim of "no latency" is even possible/reasonable regardless of the tech involved?
I do not enjoy being blunt, but the author seem to have borrowed a page from a “that” conferencing company’s marketing playbook by making very questionable claims.
It’s a nice project, but:
> Zipcall is built radically different. We left behind slow bulky servers, opting for decentralized peer to peer calling. We engineered a platform with maximum video quality and low latency.
Translation: it uses WebRTC or we didn’t invent anything — it uses technology built into your browser.
> State of the art VP9 video compression combined with our scaling optimization makes your calls crystal clear.
Same as above (assuming you’re browser supports VP9).
> Breakthrough peer to peer WebRTC technology means your video goes directly to the other person without a server. No middleman. No extra stops.
Same as above.
> End to end state of the art encryption means your calls are exactly that. Your calls.
How exactly?
It’s a nice project, but:
> Zipcall is built radically different. We left behind slow bulky servers, opting for decentralized peer to peer calling. We engineered a platform with maximum video quality and low latency.
Translation: it uses WebRTC or we didn’t invent anything — it uses technology built into your browser.
> State of the art VP9 video compression combined with our scaling optimization makes your calls crystal clear.
Same as above (assuming you’re browser supports VP9).
> Breakthrough peer to peer WebRTC technology means your video goes directly to the other person without a server. No middleman. No extra stops.
Same as above.
> End to end state of the art encryption means your calls are exactly that. Your calls.
How exactly?
Hey how is this better than the Janus webrtc server? It's been developed for a decade, and could flip a page like this in an hour or so. I'm genuinely curious how you could surpass it in stealth, like minus the marketing fluff.
https://janus.conf.meetecho.com/videoroomtest.html
https://janus.conf.meetecho.com/videoroomtest.html
We changed the title from "Show HN: Zipcall.io – Peer to peer browser video calling with no latency". Show HN is for sharing something that you've personally created (please see the rules: https://news.ycombinator.com/showhn.html). And "no latency" sounds more baity than reasonable.
So is p2p really bad when dealing with lots of users? Because now instead of you sending your video to a central server, you are now having to send your video to every single person while still receiving the video of everyone. So your upload usage must go through the roof.
Yes, absolutely. Not only bandwidth but CPU usage as you must encrypt and decrypt the video for every participant separately
Hopefully proxy re-encryption will solve this soon.
(disclaimer: this is what I work on)
(disclaimer: this is what I work on)
Sounds interesting! Do you have a link for this in regards to research done on p2p streaming?
You know, strangely, we've never published anything about (nor done any research specifically on) the prospects for private p2p streaming, even though it's something we discuss frequently on our discord.
Once we get this thing launched, we'll right that wrong.
Once we get this thing launched, we'll right that wrong.
Most calls don't have lots of users, so this is a good tradeoff for many use cases given the security and quality advantages.
Also, networks are getting faster, and so the nr of supportable participants in p2p video calls goes up and conceivably stops being an issue in some years. Many users already have fast enough networks for this today.
Also, networks are getting faster, and so the nr of supportable participants in p2p video calls goes up and conceivably stops being an issue in some years. Many users already have fast enough networks for this today.
To achieve "no latency", you have to remain completely still.
I am excited for more open-source video-calling tools, but I am also confused by how this "provides video quality and latency simply not available with traditional technology."
A quick glance at the readme suggests that this negotiates peer-to-peer connections using Twilio. But it's not just that it's p2p, right? Since there are a ton of p2p video-calling tools out there, most memorably to me the original Skype before Microsoft bought it.
A quick glance at the readme suggests that this negotiates peer-to-peer connections using Twilio. But it's not just that it's p2p, right? Since there are a ton of p2p video-calling tools out there, most memorably to me the original Skype before Microsoft bought it.
I tried this with friends, and from my phone to their laptop (and another's desktop), it didn't work.
In comparison, Jitsi sort-of worked on the same devices (but screen share was limited to 5 FPS).
In comparison, Jitsi sort-of worked on the same devices (but screen share was limited to 5 FPS).
Tried it out with a friend, both of us living close by, on ethernet, both on the same gigabit fiber ISP.
It was the same bad WebRTC quality, perhaps even worse as my video preview was really laggy.
It was the same bad WebRTC quality, perhaps even worse as my video preview was really laggy.
Does this work smartphones or tablets via specific browsers?
There are many comments with P2P and serverless together. How can this work when the users are not on the same network?
WebRTC uses UDP holepunching via STUN, it's built into almost all browsers and there are free STUN servers online. If you have some types of more tricky networks (usually symmetric NAT or more tricky firewalls) you need TURN which basically proxies the encrypted stream over TCP via the TURN server, but most home and smaller networks can do holepunching.
You still need signaling of the SDP offer, but that can be done via email/sms/whatever if you really don't want to have a server at all.
This service is just run-of-the-mill WebRTC, nothing special about it though.
You still need signaling of the SDP offer, but that can be done via email/sms/whatever if you really don't want to have a server at all.
This service is just run-of-the-mill WebRTC, nothing special about it though.
Nice, only missing one essential feature (unless I can't find it): the ability to set the device I/O.
https://jitsi.org/ diff?
Every tom, dick & harry now with WebRTC & TURN servers is here.
Nice work, some really nice touches in the UX. Keep working on it!
Great marketing page. Gotta love the fluff!
There's another post on Show HN right now with this same link.
I tried it out with my friend and not gonna lie the video quality was really good. And screen sharing is a nice feature. +1 for open source
You created an account just to say that?