Hacker News Reader

Comment by ArlenBales | Hacker News Reader

What WebRTC apps can we expect will be mainstream in, say, 6 years? I'm just trying to picture what this technology will allow (or replace).

View on HN

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

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.

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

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.

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

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

Stockholm.

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

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

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

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.

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

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.

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

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.

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

I look at it as WebRTC bringing the browser closer to an OS, in terms of the capabilities offered by the browser to application developers, out-of-the-box and without needing to convince or have users install something.

In terms of replacing, the obvious ones (as mentioned) are applications like Hangouts, Skype, GoToMeeting, etc.

In terms of enabling, time will tell but I try to think about what kinda of applications were possible before but not practical, because of the need to get everyone to install something. Hopefully this will increase the competitiveness of web to apps.

Well as of right now, my browser based real-time action game won't suffer from head-of-line queueing in TCP based Websockets on Safari.

Applications that rely on P2P data channels combined with end-to-end encrypted signalling like https://saltyrtc.org/ might also be an interesting area.

One of the projects using WebRTC data channels right now is Threema Web to connect smartphone and browser across networks without trusting a server: https://github.com/threema-ch/threema-web (Disclaimer: I'm involved in development)

People can make web apps that communicate with each other without paying for servers - hobbyists, students, developers in third world countries etc. Collaboration tools focused on local or niche things, text / video chat, multiplayer games, etc.

WebRTC can communicate on the near network without roundtrip to ISP uplink, so it can get high bandwidth in managed environments (industrial etc).

We at Lookback use WebRTC to do live streaming research sessions for desktop, iOS, and Android. Works pretty neat, even though you need a SFU (a rebroadcaster) to support heavier load than a few peers watching. So the style of doing P2P for video sort of gets lost anyway ..

Application neutral WebRTC rebroadcasting becomes a commodity this way though, so it should become quite cheap.

Reply on news.ycombinator.com