I use appear.in every day. 1-click video chat with no account sign up. The ease of launching is what keeps me coming back, even though it seems a little buggy now and then (which might be the early WebRTC support, who knows).
I actually used this a couple days ago for an interview. Cool stuff. The UI needs work, but functionality wise, really impressive. The quality was great and there were 3 people on the call. I'm not sure how it'll handle much more than that, but it worked great without any hiccups.
Just looking at startups is not enough to evaluate the impact of WebRTC. Call center tech companies worth their chop have been working with this tech for a while now as it will save money and lower the barrier of entry for their customers.
The other companies paying attention to this are the chat companies/products (slack, hipchat, etc.) - having really simple reliable calling and videochat in their products is going to be a competitive feature going forward.
Startups 100% focused on WebRTC? not many as per startup/high growth definition... The question is tricky, but I'd say that some of the startups using WebRTC as a key part of their offer are: Twilio, Tokbox, Plivo, Tropo, Slack....
We just launched a hardware video conferencing device that uses WebRTC. https://pluot.co
We route all media streams peer-to-peer. Which gives you the lowest possible latency and highest possible quality on a decent network connection. But, as other comments here have said, using a mesh topology has the downside of degrading badly if you have more than four (or so) participants in a call.
We'll add bridging in a future release, to support larger meetings, but it's actually fairly difficult to make a "routing media through the cloud in real time" architecture rock solid -- high quality and reliable for everyone, all the time. We've got customers in eight countries, so far, for example. So we'll need servers in multiple data centers, but somebody on an international call will always be farther from the bridge than is ideal.
We've surveyed a lot of people about video conferencing, and there's a lot of dissatisfaction with Hangouts and other similar products, much of which comes down to call quality, much of which is attributable to the difficulty of bouncing media streams through centralized servers.
We were in the most recent YC batch (W16) and a bunch of YC companies use our stuff. The basic idea is that big screens are super useful for team meetings, engineering standups, customer demos, etc. But big-screen video conferencing hardware has always been really expensive, or something you have to cobble together yourself. We're turnkey, set up in five minutes, are super easy to use, designed for getting real work done, and the hardware is free. You just pay $50/month per room, and there's no commitment (you can send us back the hardware and cancel any time).
You can try the Chrome browser version of our call stack from any laptop/desktop: https://pluot.co/new -- that bounces your browser to a new, unique, permanent meeting URL.
We've been following the Apple WebRTC development for a while, because we'd love to support Safari with no plugins, just like we can Chrome. We're hoping for full mobile WebKit support, too.
> We're turnkey, set up in five minutes, are super easy to use, designed for getting real work done, and the hardware is free. You just pay $50/month per room, and there's no commitment (you can send us back the hardware and cancel any time).
So, am I understanding it correctly that your main distinction from Google’s Hangouts-based offering is the pricing model? See https://www.google.com/work/chrome/devices/for-meetings/ (800 USD one-time). I haven’t personally set it up (just used it a lot), so I’m not entirely sure if your statement “designed for getting real work done” implies that Google’s lacks in that regard…?
Pricing is a difference. But we also think our UX is easier, in general, and a better fit for project, design, and engineering meetings. We made lots of little UI choices that we think add up to a different level of ease and productivity. Here are the big things:
We support two TVs (if you have two), and two simultaneous screen shares.
Our hardware has WiFi, in addition to Ethernet.
You control a Pluot box using your phone or laptop. So our "software remote control" always shows you only options that make sense for whatever the state of the Pluot call is, at the moment. There's no remote control to learn or lose. And we can continually update the "software remote control" to improve and simplify things.
Hangouts can be futzy because of how Google thinks about identity. It's pretty common for people to have trouble getting calendar invites and joining meetings because they have multiple email addresses but the Google Apps/Hangouts don't treat all of those email addresses equally. We opted for a "no sign in" approach, after doing a lot of user testing. Calendar integration and "identity" is great, when it works, but a real pain when it doesn't. Google's tight integration of Hangouts, Apps, and sign-in is a double edged sword.
Leaning on the Google WebRTC stack for the software that runs on the Pluot hardware device has been fun and interesting. We wrap Chromium (via Electron nee Atom Shell) with a UI designed to take full advantage of the HD TV (or two TV's) pixels and a provide one-click meeting start via any browser that has been paired with the room as a remote control using code displayed on the TV.
The web client uses largely the same code as the hardware device to perform its call machinery and screen shares.
We'll try to write more about this in the days to come, this week we're turning screwdrivers in the garage to ship orders, and updating the web layouts to be consistent with the in-room experience.
We do notice however, that the quality and performance of current webrtc videochat depends a lot on different conditions and we believe that it is still somewhat early for a robust experience all around. This will hopefully change when new codecs become mainstream.
A lot of our current clients are attracted by the videochat option, but in practice just use our co-browsing solution combined with a phone call. It is just very annoying if you want to give a remote product demo to a prospect and you'll need to spend time debugging audio/video issue's.
I wanted to like Talky but I tried having a large group conversation there (10-12 people) and it was laggy, some people couldn't see other people, and other people would drop from the call randomly. A few of us had fiber connections but it didn't seem to make any difference on the connection quality or reliability. We had to move to Hangouts just to be able to hear and see each other clearly.
Peer to peer in WebRTC is limiting and we suggest no more than 4 participants. If you want more than 4 you can use a Selective Forwarding Unit (SFU) such as Jitsi or a Multipoint Conferencing Unit (MCU). WebRTC is more than peer-to-peer but it depends on the implementation.
If you need some help or have questions please contact us at hi@blaccspot.com or visit our website at https://www.blaccspot.com
This is an important distinction to say P2P webrtc is limiting. WebRTC is just a collection of protocols, codecs, etc. There isn't anything stopping you from using WebRTC as a user endpoint that talks to a centralized server. I used google's java wrappers included in their WebRTC implementation to get a toy server working.
I played with the idea of relaying a stream across multiple nodes and it works. What I was doing was kinda silly I guess since it is way to cpu intensive to open so many media streams, but the general idea works. I guess it would be better to have the user endpoint talk to the server through a mediastream and then transcode the data for consumption like other systems do it.
I'm sure it's amateur compared to a project like Jitsi, but was still interesting to get working. I haven't played with it in several months but the code was here: https://github.com/jgrowl/livehq
One of the fundamental limitations of WebRTC is that the protocol is by nature peer-to-peer, so group video chat is a many to many (every client sends their video stream to every other client) network bandwidth hog!
I am extremely impressed by appear.in, however, with any more than 4 people on video chat, even with everyone on broadband connections, it became laggy and choppy at 5 and 6 participants. The reason is simple: as soon as 1 person consumes their upstream bandwidth by sending their video stream to 5 or 6 other clients, their video/audio becomes unstable, and it becomes impossible to communicate when a few people are experiencing that.
Unless everyone is on a local fiber gigabit network, I wouldn't expect WebRTC to work well with group video chat of any more than a half dozen clients at a time.
Hangouts and other server-based video chat systems can certainly handle more because they centralize and multiplex the client streams.
Now i haven't worked with webRTC in a little over a year, and my time with it was only working with data-streams, but could you have each client send a "thumbnail" size to everyone, and only send the full-size when talking or when "active" by some other means?
The client would still need to send the full size stream to every other client "when talking" so you have the same problem if the client's upstream is < 5 mbps.
You aren't! This is just a hard design problem -- mesh topologies degrade rapidly beyond two-party communications, mixer topologies introduce lag and quality issues during the compositing phase, and router topologies are still being proved out (but are probably the best option for not-huge multiparty communications). There's no silver bullet, but several options that force reasonable tradeoffs in design.
Exactly, it's just a tough problem to solve. As you so eloquently stated, the server-based solutions all introduce a terrible amount of latency (500ms-1 sec+ round trip) so they're not a silver bullet either.
The impressive things about WebRTC like appear.in are:
- Video/audio quality is extremely good - better than almost any other server-based video chat.
- Latency is extremely low because of it's direct peer-to-peer communication method. It's awesome having video chat that is <20ms round trip latency (assuming you're all in the same geographic/metropolitan area).
- HTTPS/TLS/SSL gives you end-to-end encryption, which is very nice to have.
At the cost of very high bandwidth due to the mesh topology.
I just meant that I felt a little silly for overlooking something like that.
One of my biggest pet-peeves is when people swoop into a field they know very little about and proclaim they figured it all out, and i kind of feel like i did that here a little bit and it bothers me.
I don't know of any client that settles for "good enough" based on available bandwidth. Even just audio is good enough a lot of the time (apart from one person screen-sharing); anything beyond that should be a bonus!
In general though the solution requires a server somewhere to "un" peer-to-peer everything.
vector.im and the Matrix protocol in general uses webrtc for the audio / visual calling part of a messaging protocol. It has additional functionality baked into Matrix itself for the signaling part.
