What are some of the notable startups in WebRTC space?
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.
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.
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…?
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.
Startups whose core value proposition includes WebRTC might be most of those doing live video customer service, like http://liveninja.com/
Y Combinator had a few in the last batches, like http://www.breakoutroom.co/
If you need some help or have questions please contact us at hi@blaccspot.com or visit our website at https://www.blaccspot.com
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
The actual server code is here: https://github.com/jgrowl/livehq/tree/master/media/src/main/...
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.
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.
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.
In general though the solution requires a server somewhere to "un" peer-to-peer everything.
Streaming video internally at large enterprises (facebook, ericsson, aol). Things like CEO monthly video calls, etc.