Hacker News Reader

Comment by torginus | Hacker News Reader

What's wrong with WebRTC? Other than it not being simple. In my experience it's supported well enough by browsers. On the hosting side, you've got Google's C++ implementation, or you there's a GStreamer backend, so you can hook it up with whatever GStreamer can output. In the stuff I'm doing for work, we can get well below 100ms latency out of it. Since Google uses it for Stadia, i'm pretty sure it can do far better than that? What do you need low latency for, what's your use case? Video conferencing? App/Game streaming?

View on HN

Cost and scale. HTTP video is significantly cheaper to deliver because of the robust and competitive CDN market.

You can deliver all your video via WebRTC with lower latency, but your bandwidth bill will be an order of magnitude higher.

But if you are using a CDN you are not really streaming, are you?

Love this. A great point. HLS via CDN is really just "downloading files but the source is provided kinda fast"

"Streaming" in the media industry just means you don't need to download the entire file before playing it back. The majority of streaming services use something like HLS or DASH that breaks up the video into a bunch of little 2 to 10 seconds files. The player will then download them as needed.

But even then, many CDNs CAN "stream" using chunked transfer encoding.

Having to download the whole file before playing it back is kind of the exception, isn't it ?

As the article says, HLS or DASH are specifically about not having to suffer through buffering by auto-dialing quality down, otherwise you can also start viewing during download with the browser <video> tag, over FTP with VLC, or even with peer to peer software like eMule or torrents !

I'm not sure what "real" streaming would even be ? (It probably wouldn't be over HTTP...)

It's just packet switching with much larger packets, the streaming you're thinking of is essentially the same, just with 16-50 ms sample size rather than 2-10 seconds.

Yeah as the sibling comment mentions these WebRTC implementations do not scale. While you "can hook it up" for hyper-specific applications and use cases, it does not scale to say an enterprise, where a single SA needs to support LL streaming out to tens of thousands of users.

I imagine the (proprietary) stadia implementation is highly tuned to that specific implementation, with tons of control over the video source (cloud GPUs) literally all the way down to the user's browser(modern chrome implementations). Plus their scale likely isn't in the tens of thousands from a single origin. Even still, I continue to be blown away by the production latency numbers achieved by game streaming services.

And my use-case is no use-case or every use-case. I'm just a lowly engineer that has seen this gap in the industry.

What makes you write that “these” WebRTC implementations do not scale? Which implementations do you have in mind and why do you think they do not scale? Where do they fall over, and at what point?

Well, clearly it wouldn't work for something with always unique files like video-conferencing or game streaming, but with a limited number of files we already have an example of a non-HTTP working solution : Popcorn Time.

Also PeerTube seems to have found a way to combine the cheapness of peer to peer and the reliability of an (HTTP?) dedicated server, I wonder how did they achieve this ?

Reply on news.ycombinator.com