4 ms·

That's the $1B question. The obvious application is the video conferencing style hangouts, Skype (which are using WebRTC already). The nice thing about having

That's the $1B question. The obvious application is the video conferencing style hangouts, Skype (which are using WebRTC already). The nice thing about having video conf capabilities in the browser is that you can embed it in any web page and start do interesting things with it - like interactive lectures. Improved gaming networking is another vertical. We've built Peer5 (W17) on top of WebRTC to create a P2P CDN for Video streaming

ArlenBales 9y ago
What about a WebRTC version of Twitch.tv? Is that feasible in 5 or 10 years? Twitch does transcoding and I'm not sure how transcoding would work with WebRTC.
- shacharz 9y ago
  What do you mean exactly by that? You want to replace the contribution side (camera to server) by WebRTC or delivery side (server to screen) or both? Contribution: there are platforms who already uses WebRTC instead of rtmp to stream the live camera feed. You can use tokbox's apis for example. Delivery: This is where it gets more tricky, the nice thing about http based streaming like HLS and DASH is that it's cacheable just like any other file served over http - making it extremely scalable and that's how most CDNs operate today. Changing that part into WebRTC has it's benefits like low latency but has a huge degradation in scaling complexity because of the connection state oriented nature of WebRTC, there are companies trying to build that as well e.g: Red5
- Nullabillity 9y ago
  It would probably be possible for smaller communities today, given how cheap bandwidth already is. For comparison, I'm currently paying ~$13/mo for a (symmetric) gigabit connection. The main reasons for transcoding are downstream bandwidth usage and codec support. WebRTC mandates VP8, so codecs shouldn't be an issue. Downstream bandwidth usage probably wouldn't be a major concern when it's viable to stream at 1080p to thousands of viewers from a home connection (though I doubt that's going to happen soon). So you could probably ignore transcoding entirely. However, marketing would probably be an issue, since this architecture would prevent streamers from having more than about a hundred watchers, meaning that the big fish would stick to Twitch. That said, I suppose you could have a failover system, where larger streamers would switch to a relay-based system.
  - TD-Linux 9y ago
    You can also fall over to a classic client/server model with WebRTC for one to many broadcasting, while still keeping the advantages of very low latency (and reusing much of the same code).
  - Gaelan 9y ago
    Where do you live? Internet is way more expensive in the US.
    - Nullabillity 9y ago
      Stockholm.
      - MBCook 9y ago
        If you're lucky enough to have Google Fiber in the US it's $70/mo for symmetric gig, IIRC.
- PaulBGD_ 9y ago
  That actually already exists and it's owned by Microsoft: https://mixer.com/ https://mixer.com/
vvanders 9y ago
I doubt you'll see gaming pick up WebRTC for many of the reasons that Glenn build netcode.io[1]. It's overly complex and doesn't guarantee UDP which is a non-starter for most games. [1] http://new.gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ http://new.gafferongames.com/post/why_cant_i_send_udp_packet... / https://github.com/networkprotocol/netcode.io https://github.com/networkprotocol/netcode.io
- TD-Linux 9y ago
  It guarantees UDP for all of the cases when UDP would work. You can choose to not use TCP if you like, though I think most games would actually desire a TCP fallback.
  - vvanders 9y ago
    Pretty sure you don't want TCP(as the below article about X-Wing lays out pretty well) http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php http://www.gamasutra.com/view/feature/131781/the_internet_su...
  - brkho 9y ago
    WebRTC Data Channels don't actually let browsers send arbitrary UDP packets over the wire; rather, they only let you send SCTP packets tunneled over UDP. This distinction sounds pedantic because you can configure SCTP to deliver unreliable and unordered messages just like UDP, but there are some important caveats. For example, one of the benefits of UDP in real-time gaming is that packets can be dropped with minimal impact because it doesn't have head of line blocking. However, SCTP mandates congestion control which will start buffering your outgoing packets if it detects a minute or so of sustained packet loss (at least in libwebrtc). While congestion control is generally a good thing, in this case, it causes the game to grind to a halt. In addition, there is some overhead to sending the SCTP metadata which is suboptimal in bandwidth-heavy use cases like synchronizing a large physics simulation or supporting slower connections. That being said, I'm very excited about WebRTC and its inclusion in Safari. It's not a silver bullet that exposes a simple UDP interface, but it's a welcome alternative to WebSockets for use in real-time games.

ArlenBales 9y ago

What about a WebRTC version of Twitch.tv? Is that feasible in 5 or 10 years? Twitch does transcoding and I'm not sure how transcoding would work with WebRTC.

shacharz 9y ago
What do you mean exactly by that? You want to replace the contribution side (camera to server) by WebRTC or delivery side (server to screen) or both? Contribution: there are platforms who already uses WebRTC instead of rtmp to stream the live camera feed. You can use tokbox's apis for example. Delivery: This is where it gets more tricky, the nice thing about http based streaming like HLS and DASH is that it's cacheable just like any other file served over http - making it extremely scalable and that's how most CDNs operate today. Changing that part into WebRTC has it's benefits like low latency but has a huge degradation in scaling complexity because of the connection state oriented nature of WebRTC, there are companies trying to build that as well e.g: Red5
Nullabillity 9y ago
It would probably be possible for smaller communities today, given how cheap bandwidth already is. For comparison, I'm currently paying ~$13/mo for a (symmetric) gigabit connection. The main reasons for transcoding are downstream bandwidth usage and codec support. WebRTC mandates VP8, so codecs shouldn't be an issue. Downstream bandwidth usage probably wouldn't be a major concern when it's viable to stream at 1080p to thousands of viewers from a home connection (though I doubt that's going to happen soon). So you could probably ignore transcoding entirely. However, marketing would probably be an issue, since this architecture would prevent streamers from having more than about a hundred watchers, meaning that the big fish would stick to Twitch. That said, I suppose you could have a failover system, where larger streamers would switch to a relay-based system.
- TD-Linux 9y ago
  You can also fall over to a classic client/server model with WebRTC for one to many broadcasting, while still keeping the advantages of very low latency (and reusing much of the same code).
- Gaelan 9y ago
  Where do you live? Internet is way more expensive in the US.
  - Nullabillity 9y ago
    Stockholm.
    - MBCook 9y ago
      If you're lucky enough to have Google Fiber in the US it's $70/mo for symmetric gig, IIRC.
PaulBGD_ 9y ago
That actually already exists and it's owned by Microsoft: https://mixer.com/ https://mixer.com/

vvanders 9y ago

I doubt you'll see gaming pick up WebRTC for many of the reasons that Glenn build netcode.io[1]. It's overly complex and doesn't guarantee UDP which is a non-starter for most games. [1] http://new.gafferongames.com/post/why_cant_i_send_udp_packets_from_a_browser/ http://new.gafferongames.com/post/why_cant_i_send_udp_packet... / https://github.com/networkprotocol/netcode.io https://github.com/networkprotocol/netcode.io

TD-Linux 9y ago
It guarantees UDP for all of the cases when UDP would work. You can choose to not use TCP if you like, though I think most games would actually desire a TCP fallback.
- vvanders 9y ago
  Pretty sure you don't want TCP(as the below article about X-Wing lays out pretty well) http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php http://www.gamasutra.com/view/feature/131781/the_internet_su...
- brkho 9y ago
  WebRTC Data Channels don't actually let browsers send arbitrary UDP packets over the wire; rather, they only let you send SCTP packets tunneled over UDP. This distinction sounds pedantic because you can configure SCTP to deliver unreliable and unordered messages just like UDP, but there are some important caveats. For example, one of the benefits of UDP in real-time gaming is that packets can be dropped with minimal impact because it doesn't have head of line blocking. However, SCTP mandates congestion control which will start buffering your outgoing packets if it detects a minute or so of sustained packet loss (at least in libwebrtc). While congestion control is generally a good thing, in this case, it causes the game to grind to a halt. In addition, there is some overhead to sending the SCTP metadata which is suboptimal in bandwidth-heavy use cases like synchronizing a large physics simulation or supporting slower connections. That being said, I'm very excited about WebRTC and its inclusion in Safari. It's not a silver bullet that exposes a simple UDP interface, but it's a welcome alternative to WebSockets for use in real-time games.