4 ms·

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-co

We're fans of webrtc-rs, but interop considerations pretty much mean that building on top of libwebrtc is necessary for our client libraries for now. `daily-core` is signaling, the (always evolving) low-level trickery needed to scale calls to 10,000+ participants, state management, and an opinionated internal API that lets us efficiently maintain public-facing API features like track management, and device selection.

yolo3000 4y ago
Are there use cases for calls with so many participants?
- tebbers 4y ago
  Company earnings calls with analysts? Livestreams?
- dgunay 4y ago
  WebRTC is some of the lowest latency streaming you can get, so I would imagine any realtime event with a large broadcasting audience would benefit. Interactive/2-way though, that's another story.
- VWWHFSfQ 4y ago
  People have started turning to webrtc for broadcast streaming (1->many) instead of hls/dash because of the lower glass-to-glass latency. But it has scalability problems which makes it enormously expensive comparatively. There are low-latency variants of HLS and DASH emerging now though
- vr000m 4y ago
  One thing to consider is if you would have One API and a few knobs to control the experience and not have to worry about the underlying protocol-, reliability-, latency- aspects to build that experience. (particularly not worry about the shenanigans around tuning RTMP, RTP, HLS, or webrtc) There are some use-cases in every industry. * Finance/Company: earnings calls as mentioned before, all-hands meetings at companies (with several people queuing for questions and answers) * Live Events (music or talkshows) * Tutoring or education in general. * Healthcare and education -- Surgeries which are broadcast to several schools and have active collaboration from some doctors. The large-scale interaction can begin much earlier before the surgery.
mwcampbell 4y ago
Have you considered releasing your Rust bindings for libwebrtc separately, either as open source or as another commercial product? I could have really used that for a desktop application I started developing a few months ago. In the absence of such bindings, I went with Electron instead, reluctantly. And no, I don't think your high-level API would be a good fit; what I'm doing with WebRTC is too custom. Edit: Also, webrtc-rs doesn't work for me either; AFAIK, it doesn't yet have enough of the media stack, including hard stuff like echo cancellation.
- Sean-Der 4y ago
  You should help out with the gaps in the media stack! That is the only way it will get better :) I don't believe echo cancellation is a hard problem either. I don't know the specific details, but I have heard this argument so many times. People told me that unless you were a developer at a big company you can't build DTLS, SCTP and RTP Congestion Control either. Maybe the community implementations aren't as good yet, but I think it is a tortoise vs hare.
  - regexident 4y ago
    > You should help out with the gaps in the media stack! That is the only way As it happens I am the author of the audio-buffer and constraint-algorithm implementations in webrtc-rs/media: https://github.com/webrtc-rs/media/commits?author=regexident https://github.com/webrtc-rs/media/commits?author=regexident So even though we are not using webrtc-rs in Daily today, we are (or at least I am) contributing to it, in hopes of it becoming a feasible option at some point.

yolo3000 4y ago

Are there use cases for calls with so many participants?

tebbers 4y ago
Company earnings calls with analysts? Livestreams?
dgunay 4y ago
WebRTC is some of the lowest latency streaming you can get, so I would imagine any realtime event with a large broadcasting audience would benefit. Interactive/2-way though, that's another story.
VWWHFSfQ 4y ago
People have started turning to webrtc for broadcast streaming (1->many) instead of hls/dash because of the lower glass-to-glass latency. But it has scalability problems which makes it enormously expensive comparatively. There are low-latency variants of HLS and DASH emerging now though
vr000m 4y ago
One thing to consider is if you would have One API and a few knobs to control the experience and not have to worry about the underlying protocol-, reliability-, latency- aspects to build that experience. (particularly not worry about the shenanigans around tuning RTMP, RTP, HLS, or webrtc) There are some use-cases in every industry. * Finance/Company: earnings calls as mentioned before, all-hands meetings at companies (with several people queuing for questions and answers) * Live Events (music or talkshows) * Tutoring or education in general. * Healthcare and education -- Surgeries which are broadcast to several schools and have active collaboration from some doctors. The large-scale interaction can begin much earlier before the surgery.

mwcampbell 4y ago

Have you considered releasing your Rust bindings for libwebrtc separately, either as open source or as another commercial product? I could have really used that for a desktop application I started developing a few months ago. In the absence of such bindings, I went with Electron instead, reluctantly. And no, I don't think your high-level API would be a good fit; what I'm doing with WebRTC is too custom. Edit: Also, webrtc-rs doesn't work for me either; AFAIK, it doesn't yet have enough of the media stack, including hard stuff like echo cancellation.

Sean-Der 4y ago
You should help out with the gaps in the media stack! That is the only way it will get better :) I don't believe echo cancellation is a hard problem either. I don't know the specific details, but I have heard this argument so many times. People told me that unless you were a developer at a big company you can't build DTLS, SCTP and RTP Congestion Control either. Maybe the community implementations aren't as good yet, but I think it is a tortoise vs hare.
- regexident 4y ago
  > You should help out with the gaps in the media stack! That is the only way As it happens I am the author of the audio-buffer and constraint-algorithm implementations in webrtc-rs/media: https://github.com/webrtc-rs/media/commits?author=regexident https://github.com/webrtc-rs/media/commits?author=regexident So even though we are not using webrtc-rs in Daily today, we are (or at least I am) contributing to it, in hopes of it becoming a feasible option at some point.