Hacker News Reader

Comment by xuejie | Hacker News Reader

I think Talky(https://talky.io/) is a pioneer here.

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.

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.

Well i'm an idiot!

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.

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.

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 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.

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

The actual server code is here: https://github.com/jgrowl/livehq/tree/master/media/src/main/...

I had this same experience with talky. I think that's why free.gotomeeting.com is limited to 3 as well.

talky.io is great!

Reply on news.ycombinator.com