4 ms·

Anyone know what the best streaming solution for browser <-> browser video calling is? It probably has to be built on top of WebRTC but I'm wondering if there a

Anyone know what the best streaming solution for browser <-> browser video calling is? It probably has to be built on top of WebRTC but I'm wondering if there are codecs and forward error correction algorithms out there already in Javascript to use.

stanlarroque 8y ago
Kurento is an excellent open source solution for this use-case. Check out the project here: https://github.com/Kurento/kurento-media-server https://github.com/Kurento/kurento-media-server
kwindla 8y ago
For small numbers of people in a call (say, n < 5), the "best" -- meaning lowest latency -- solution is direct browser to browser WebRTC connections. Both Chrome's and Firefox's WebRTC implementations have quite good FEC built in. And sending UDP packets directly between peers will have much lower latency than routing through a media server. Of course, sometimes peer-to-peer won't work for you. Maybe you have requirements that push you towards routing media through a server. (Content filtering, or compositing video or mixing audio, for example.) Or maybe you have more than a few people in a call. If so, upstream bandwidth and encoding become bottlenecks for mesh/peer-to-peer. Finally, some firewalls won't allow UDP traffic from/to computers behind them, so you'll need to route UDP through a central server, or (much worse) tunnel over TCP. Back on the subject of latency and error correction in WebRTC, here are some fun links: Draft spec for FEC in WebRTC: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08 https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08 Mozilla article from when they first turned on Opus FEC. Includes sample audio for calls with 19% packet loss. (19% packet loss is very, very bad. My startup makes a browser-to-browser video calling tool, and we try hard to deal well with packet loss that high, but it's a losing battle.) https://blog.mozilla.org/webrtc/audio-fec-experiments/ https://blog.mozilla.org/webrtc/audio-fec-experiments/ Notes from the very knowledgeable folks at Callstats.io about WebRTC FEC. Covers some of the same material as this thread's original post: https://www.callstats.io/2016/11/09/how-to-recover-lost-media-packets-in-webrtc-with-fec/ https://www.callstats.io/2016/11/09/how-to-recover-lost-medi... Tsahi Levent-Levi's benchmarks showing how a few different media servers perform in the context of 10% packet loss: https://testrtc.com/webrtc-media-server-packet-loss/ https://testrtc.com/webrtc-media-server-packet-loss/

stanlarroque 8y ago

Kurento is an excellent open source solution for this use-case. Check out the project here: https://github.com/Kurento/kurento-media-server https://github.com/Kurento/kurento-media-server

kwindla 8y ago

For small numbers of people in a call (say, n < 5), the "best" -- meaning lowest latency -- solution is direct browser to browser WebRTC connections. Both Chrome's and Firefox's WebRTC implementations have quite good FEC built in. And sending UDP packets directly between peers will have much lower latency than routing through a media server. Of course, sometimes peer-to-peer won't work for you. Maybe you have requirements that push you towards routing media through a server. (Content filtering, or compositing video or mixing audio, for example.) Or maybe you have more than a few people in a call. If so, upstream bandwidth and encoding become bottlenecks for mesh/peer-to-peer. Finally, some firewalls won't allow UDP traffic from/to computers behind them, so you'll need to route UDP through a central server, or (much worse) tunnel over TCP. Back on the subject of latency and error correction in WebRTC, here are some fun links: Draft spec for FEC in WebRTC: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08 https://tools.ietf.org/html/draft-ietf-rtcweb-fec-08 Mozilla article from when they first turned on Opus FEC. Includes sample audio for calls with 19% packet loss. (19% packet loss is very, very bad. My startup makes a browser-to-browser video calling tool, and we try hard to deal well with packet loss that high, but it's a losing battle.) https://blog.mozilla.org/webrtc/audio-fec-experiments/ https://blog.mozilla.org/webrtc/audio-fec-experiments/ Notes from the very knowledgeable folks at Callstats.io about WebRTC FEC. Covers some of the same material as this thread's original post: https://www.callstats.io/2016/11/09/how-to-recover-lost-media-packets-in-webrtc-with-fec/ https://www.callstats.io/2016/11/09/how-to-recover-lost-medi... Tsahi Levent-Levi's benchmarks showing how a few different media servers perform in the context of 10% packet loss: https://testrtc.com/webrtc-media-server-packet-loss/ https://testrtc.com/webrtc-media-server-packet-loss/