4 ms·

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 vid

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 11y ago
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 11y ago
  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 11y ago
    Well i'm an idiot!
    - HillRat 11y ago
      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.
      - Klathmon 11y ago
        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.
      - illumin8 11y ago
        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.
- j_s 11y ago
  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.

Klathmon 11y ago

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 11y ago
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 11y ago
  Well i'm an idiot!
  - HillRat 11y ago
    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.
    - Klathmon 11y ago
      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.
    - illumin8 11y ago
      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.
j_s 11y ago
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.