3 ms·

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 issue

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

Sean-Der 4y ago
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/ https://webrtchacks.com/zoom-avoids-using-webrtc/
- thecleaner 4y ago
  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 ?
  - kwindla 4y ago
    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-quic/ https://datatracker.ietf.org/doc/draft-engelbart-rtp-over-qu...
- avrionov 4y ago
  Zoom uses Media over DataChannels only for the browser version of their product. For the desktop and mobile clients they use their own implementation.

Sean-Der 4y ago

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/ https://webrtchacks.com/zoom-avoids-using-webrtc/

thecleaner 4y ago
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 ?
- kwindla 4y ago
  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-quic/ https://datatracker.ietf.org/doc/draft-engelbart-rtp-over-qu...
avrionov 4y ago
Zoom uses Media over DataChannels only for the browser version of their product. For the desktop and mobile clients they use their own implementation.