[shacharz]

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

[vvanders]

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_packet... / https://github.com/networkprotocol/netcode.io

[devrandomguy]

> ... there is a trend away from peer-to-peer towards client/server for multiplayer games ...

Really? Why? It seems obvious to me that communicating directly with other players would be faster than relaying messages through a server. Even if the server and the clients are all in the same building, the server is still going to add the latency of its entire stack. Unless that server is acting as a very simple stream-oriented traffic controller, then surely its latency is in the 5-20 millisecond range, at least?

I know WebRTC is complex, but minimal latency is such a critical feature for multiplayer gaming, that surely, if it works at all, then it is worth the trouble?

[imron]

> Really? Why?

Cheating. Having an authoritative server reduces the ability to cheat and limits the type of cheating that is possible.

The more you trust the client, the more cheating can affect the game.

Also, client-server scales to more players.

[vvanders]

The server also handles arbitration which can add a ton more latency if you need to determine it via consensus from all the other clients.

His lib is based on real-world pain that many game devs have hit trying to integrate WebRTC. It's the same reason you see Lua thrive while V8/etc are rarely a part of a game engine.

[TD-Linux]

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.

[brkho]

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.

[vvanders]

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

[ArlenBales]

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]

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]

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.

[Gaelan]

Where do you live? Internet is way more expensive in the US.

[Nullabillity]

Stockholm.

[MBCook]

If you're lucky enough to have Google Fiber in the US it's $70/mo for symmetric gig, IIRC.

[TD-Linux]

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

[PaulBGD_]

That actually already exists and it's owned by Microsoft: https://mixer.com/