[illumin8]

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.

[Klathmon]

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?

[illumin8]

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.

[Klathmon]

Well i'm an idiot!

[HillRat]

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.

[illumin8]

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.

[Klathmon]

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.

[j_s]

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.