4 ms·

> and will not be talking about any software in particular If you want to do something with WebRTC, definitely use libwebrtc, and definitely get acquainted wit

> and will not be talking about any software in particular If you want to do something with WebRTC, definitely use libwebrtc, and definitely get acquainted with the field trials, because that's how Google sneaks in all their best functionality.

Sean-Der 3y ago
If you want to do servers or embedded you shouldn’t. It makes sense to use in the places it was designed for though! If you are shipping a client and have needs that match its creators it’s the best choice. What features of libwebrtc in particular would you like to see in other implementations. I am very excited to see a future with [0] on the client side. [0] https://github.com/algesten/str0m https://github.com/algesten/str0m
- k8svet 3y ago
  I tried reading that a few times but don't really understand it. Can you put it in terms of what I can't do without it, or can do with it? (I do have some long-reaching webrtc background but its pretty surface level and increasingly out-dated)
  - K0nserv 3y ago
    I work on str0m along my colleagues at Lookback. We use it it to build something akin to a SFU(Selective Forward Unit) i.e. a services that forwards media between many clients in a conference setting. There are other people using it for the same purpose. I think there are some folks trying it out for client-to-client use cases, the thing that's different about that is that more is required of the ICE agent to find a network path between the clients. str0m doesn't deal with encoding or decoding media at all, but given that you provided those capabilities it should be possible to use it in e.g. a mobile app setting as part of a client implementation. This use case most likely has a few rough edges at the moment though. If you, or anyone else, has further questions don't hesitate to join the Zulip chatroom and ask away.
boushley 3y ago
An interesting take for sure. Having worked with libwebrtc on multiple occasions I've found it pretty hard to separate from the Chrome build toolchain. Especially if you're doing server work there are pure Go and pure Rust implementations that work great.
camkego 3y ago
The problem with libwebrtc is that it is really built to decode video frames being received from the network. Also the APIs are intended to accept full video frames to be encoded before being sent to the network. This is great for a browser! Not so much for an SFU or application that needs to work at the elementary stream (not uncompressed frame) level.

Sean-Der 3y ago

If you want to do servers or embedded you shouldn’t. It makes sense to use in the places it was designed for though! If you are shipping a client and have needs that match its creators it’s the best choice. What features of libwebrtc in particular would you like to see in other implementations. I am very excited to see a future with [0] on the client side. [0] https://github.com/algesten/str0m https://github.com/algesten/str0m

k8svet 3y ago
I tried reading that a few times but don't really understand it. Can you put it in terms of what I can't do without it, or can do with it? (I do have some long-reaching webrtc background but its pretty surface level and increasingly out-dated)
- K0nserv 3y ago
  I work on str0m along my colleagues at Lookback. We use it it to build something akin to a SFU(Selective Forward Unit) i.e. a services that forwards media between many clients in a conference setting. There are other people using it for the same purpose. I think there are some folks trying it out for client-to-client use cases, the thing that's different about that is that more is required of the ICE agent to find a network path between the clients. str0m doesn't deal with encoding or decoding media at all, but given that you provided those capabilities it should be possible to use it in e.g. a mobile app setting as part of a client implementation. This use case most likely has a few rough edges at the moment though. If you, or anyone else, has further questions don't hesitate to join the Zulip chatroom and ask away.

boushley 3y ago

An interesting take for sure. Having worked with libwebrtc on multiple occasions I've found it pretty hard to separate from the Chrome build toolchain. Especially if you're doing server work there are pure Go and pure Rust implementations that work great.

camkego 3y ago

The problem with libwebrtc is that it is really built to decode video frames being received from the network. Also the APIs are intended to accept full video frames to be encoded before being sent to the network. This is great for a browser! Not so much for an SFU or application that needs to work at the elementary stream (not uncompressed frame) level.