3 ms·

As someone who doesn’t know much about the two protocols: how come?

suyash 6y ago
Here is a good answer https://www.quora.com/Which-is-better-for-live-streaming-RTMP-vs-HLS-vs-WebRTC https://www.quora.com/Which-is-better-for-live-streaming-RTM...
manishsharan 6y ago
I guessing it's because Webrtc is near real-time whereas transcoding to HLS would add latency. However the advantage of HLS is that you can offload the serving of the content to a CDN or a Http server and scale horizontally. Whereas serving more webrtc clients would require fatter/bigger webrtc server. Please note I am only basing my opinion base on what I have read on HN.
dkh 6y ago
WebRTC is amazing and definitely has its uses in video streaming, but it does present a number of challenges and disadvantages. Simplified, it can have lower latency and higher reliability, but at the cost of compatibility and scalability. (Also, "higher reliability" takes a lot of work to implement properly, whereas out-of-the-box for most users it would likely be lower reliability.) For the use-cases mentioned about home security cameras and other personal or low-volume situations where you also have knowledge of and control over the playback devices, sure, you can get away with it no problem. But if you are building a streaming platform for public consumption or something, we just aren't there yet. Delivering video over WebRTC to tons of clients is much more complex than serving them chunked flat files. With HLS/DASH, your clients are just downloading tiny video files over HTTP, and they can be live or be served up by anywhere -- nginx, S3, anything. It's not much different on the server-side than how file serving has always been. WebRTC though requires each client to be connected in constant 2-way communication with the server, and the logic/work the server has to do goes up tremendously since it will be attempting to chop up and serve the exact number of bytes of video each individual client needs on-the-fly rather than each client getting the same identical 1- to 4-second chunks. This presents even more challenges if your clients are at different parts of the stream, have crappy bandwidth, etc. In terms of compatibility, WebRTC is widely prevalent, but not nearly the same as HLS/DASH. Many clients that do support it have their own quirks, limitations, etc. that need to be catered to slightly differently, especially on mobile devices. For these reasons and others, you currently see WebRTC used for broadcast right now mostly at the scale of dozens to maybe hundreds, but not more than that. What WebRTC is very useful for is p2p. It has enabled things like WebTorrent to have users be serving video to peers while they are themselves watching, reducing strain/cost on the provider. It is also clearly beneficial for things like conference calls, where there is a small number of clients talking to each other multidirectionally.

Here is a good answer https://www.quora.com/Which-is-better-for-live-streaming-RTMP-vs-HLS-vs-WebRTC https://www.quora.com/Which-is-better-for-live-streaming-RTM...

manishsharan 6y ago

I guessing it's because Webrtc is near real-time whereas transcoding to HLS would add latency. However the advantage of HLS is that you can offload the serving of the content to a CDN or a Http server and scale horizontally. Whereas serving more webrtc clients would require fatter/bigger webrtc server. Please note I am only basing my opinion base on what I have read on HN.

dkh 6y ago

WebRTC is amazing and definitely has its uses in video streaming, but it does present a number of challenges and disadvantages. Simplified, it can have lower latency and higher reliability, but at the cost of compatibility and scalability. (Also, "higher reliability" takes a lot of work to implement properly, whereas out-of-the-box for most users it would likely be lower reliability.) For the use-cases mentioned about home security cameras and other personal or low-volume situations where you also have knowledge of and control over the playback devices, sure, you can get away with it no problem. But if you are building a streaming platform for public consumption or something, we just aren't there yet. Delivering video over WebRTC to tons of clients is much more complex than serving them chunked flat files. With HLS/DASH, your clients are just downloading tiny video files over HTTP, and they can be live or be served up by anywhere -- nginx, S3, anything. It's not much different on the server-side than how file serving has always been. WebRTC though requires each client to be connected in constant 2-way communication with the server, and the logic/work the server has to do goes up tremendously since it will be attempting to chop up and serve the exact number of bytes of video each individual client needs on-the-fly rather than each client getting the same identical 1- to 4-second chunks. This presents even more challenges if your clients are at different parts of the stream, have crappy bandwidth, etc. In terms of compatibility, WebRTC is widely prevalent, but not nearly the same as HLS/DASH. Many clients that do support it have their own quirks, limitations, etc. that need to be catered to slightly differently, especially on mobile devices. For these reasons and others, you currently see WebRTC used for broadcast right now mostly at the scale of dozens to maybe hundreds, but not more than that. What WebRTC is very useful for is p2p. It has enabled things like WebTorrent to have users be serving video to peers while they are themselves watching, reducing strain/cost on the provider. It is also clearly beneficial for things like conference calls, where there is a small number of clients talking to each other multidirectionally.