Hacker News new | ask | show | jobs
by Sean-Der 1485 days ago
Yes! I have used it in production with these.

* FaceTime @ Apple https://support.apple.com/en-us/HT212619

* KVS and Chime @ AWS https://github.com/awslabs/amazon-kinesis-video-streams-webr.... Lots of security cameras and robots use it, not public though.

* Lightstream https://golightstream.com . Cloud compositing and other magic.

I also have something I am working on now that isn't public yet that is using WebRTC. Really excited to see what people build with it/what it inspires next.

It is kind of amazing everywhere you will find WebRTC. Stadia, Boston Dynamics, Zoom, Meet, Security Systems, Drones etc... It is probable that you use WebRTC in production everyday :)

1 comments

I think Zoom doesn't use WebRTC, they have their own decoder, transmission, retry layer. If you try to transmit raw frames directly, you end up with codec issues since frames have dependencies among them. E.g. VPX series cannot decide frames without a golden frame or a key frame so these need to be kept as state for a decoder. Every other intra-frame needs to refer to these frames and there's no limit usually as to how many intra-frames one can have between inter-frames (key-frame or a golden frame).
I don't work at Zoom/only have outsider information. It looks like they are using Media over DataChannels[0]. So they are still using WebRTC!

When Google announced WebCodecs/WebTransport they said Zoom was involved, so maybe they will switch to that eventually?

[0] https://webrtchacks.com/zoom-avoids-using-webrtc/

Does data channels over WebRTC enforce different semantics than say QUIC/Http2 ? I understand that the difference b/w TCP and WebRTC based comm would be application level transmission guarantee but does it really differ from UDP based HTTP implementations ?
The biggest problem with sending media over data channels is that there's no good way to do bandwidth estimation. Data channels weren't designed to be used for media, and the current WebRTC spec (and javascript implementation) doesn't expose enough control of either the codec or the network stack to implement real bandwidth estimation and bandwidth control. This is presumably the main reason that Zoom's in-browser implementation is so limited in functionality.

There's a spec for RTP over QUIC [1]. It's really cool! But obviously very early days.

[1] https://datatracker.ietf.org/doc/draft-engelbart-rtp-over-qu...

Zoom uses Media over DataChannels only for the browser version of their product. For the desktop and mobile clients they use their own implementation.