4 ms·

What advantages would this offer over jitsi meet?

kabes 6y ago
Jitsi meet is a conferencing app. You likely mean jitsi videobridge. That's the SFU part and comparable to mediasoup. Mediasoup has a bit more modern codebase and offers a rather low-level framework to build your own SFU. Whereas Jitsi videobridge is more of a ready-to-go SFU, but less flexible. Mediasoup has very good node bindings, which may or may not be an advantage to you. They offer similar (good) performance, although Mediasoup has a slight edge here. They're both very actively being kept up to date with the latest standards (in contrast with Kurento which is now as good as dead after Twilio bought the team). This is very important since both the spec and browser implementations are a fast moving target. Disadvantage of mediasoup is that it is mainly maintained by just 1 or 2 persons and not yet used as much as Jitsi, so it's a bit of a gamble to start building your product on top of that.
- ibc 6y ago
  Yep, two active developers but being just a set of libraries it's good enough. We also get nice contributions (C++ fixes and optimizations) via PR in GitHub. And we use mediasoup in different commercial products.
- micaelgallego 6y ago
  Kurento is not dead. Main contributions are on OpenVidu project, that somehow is part of Kurento (but with other name)
ibc 6y ago
Jitsi is a full application (web app, backend servers) with a specific use case: meetings (similar to Zoom or Google Meet). mediasouop is not an application but a set of server and client low level libraries to build whichever kind of audio/video applications (not just meetings). You don't "install mediasoup and configure it". You create your Node app and integrate mediasoup as you do with any other NPM dependency. Same in client side. More here: https://mediasoup.org/documentation/overview/ https://mediasoup.org/documentation/overview/ Of course, this means that you must build your application, including UI, client-server signaling, etc etc.
- ignoramous 6y ago
  > ...build whichever kind of audio/video applications... Is live streaming a use-case that's under scope? If so, can the client P2P or requires a relay server for all traffic?
  - microcolonel 6y ago
    I think there's nothing stopping you from attempting that, but you would need some pretty complex client software to get a good experience with P2P live streaming.
  - ibc 6y ago
    PornHub uses mediasoup for live cams.
    - toomuchtodo 6y ago
      That’s quite the endorsement.
      - jagannathtech 6y ago
        exactly what I was thinking :)
  - kabes 6y ago
    Well, it's webRTC. So the main use case is live video streaming. But one would need to define 'live'. webRTC is really made for sub-second latency, which you need for conversations. If you don't require this you're better of using HLS streaming. Because achieving ultra-low latency does come with tradeoffs in complexity and quality. webRTC is peer 2 peer, but that doesn't work if you have a lot of peers. That is where an SFU like mediasoup comes into the picture. That's a kind of relay server so you can send to many peers still over webRTC (thus with ultra low latency). Also, if the peers are behind firewalls, peer 2 peer also doesn't work and you need a TURN server to relay the video.

Jitsi meet is a conferencing app. You likely mean jitsi videobridge. That's the SFU part and comparable to mediasoup. Mediasoup has a bit more modern codebase and offers a rather low-level framework to build your own SFU. Whereas Jitsi videobridge is more of a ready-to-go SFU, but less flexible. Mediasoup has very good node bindings, which may or may not be an advantage to you. They offer similar (good) performance, although Mediasoup has a slight edge here. They're both very actively being kept up to date with the latest standards (in contrast with Kurento which is now as good as dead after Twilio bought the team). This is very important since both the spec and browser implementations are a fast moving target. Disadvantage of mediasoup is that it is mainly maintained by just 1 or 2 persons and not yet used as much as Jitsi, so it's a bit of a gamble to start building your product on top of that.

ibc 6y ago
Yep, two active developers but being just a set of libraries it's good enough. We also get nice contributions (C++ fixes and optimizations) via PR in GitHub. And we use mediasoup in different commercial products.
micaelgallego 6y ago
Kurento is not dead. Main contributions are on OpenVidu project, that somehow is part of Kurento (but with other name)

ibc 6y ago

Jitsi is a full application (web app, backend servers) with a specific use case: meetings (similar to Zoom or Google Meet). mediasouop is not an application but a set of server and client low level libraries to build whichever kind of audio/video applications (not just meetings). You don't "install mediasoup and configure it". You create your Node app and integrate mediasoup as you do with any other NPM dependency. Same in client side. More here: https://mediasoup.org/documentation/overview/ https://mediasoup.org/documentation/overview/ Of course, this means that you must build your application, including UI, client-server signaling, etc etc.

ignoramous 6y ago
> ...build whichever kind of audio/video applications... Is live streaming a use-case that's under scope? If so, can the client P2P or requires a relay server for all traffic?
- microcolonel 6y ago
  I think there's nothing stopping you from attempting that, but you would need some pretty complex client software to get a good experience with P2P live streaming.
- ibc 6y ago
  PornHub uses mediasoup for live cams.
  - toomuchtodo 6y ago
    That’s quite the endorsement.
    - jagannathtech 6y ago
      exactly what I was thinking :)
- kabes 6y ago
  Well, it's webRTC. So the main use case is live video streaming. But one would need to define 'live'. webRTC is really made for sub-second latency, which you need for conversations. If you don't require this you're better of using HLS streaming. Because achieving ultra-low latency does come with tradeoffs in complexity and quality. webRTC is peer 2 peer, but that doesn't work if you have a lot of peers. That is where an SFU like mediasoup comes into the picture. That's a kind of relay server so you can send to many peers still over webRTC (thus with ultra low latency). Also, if the peers are behind firewalls, peer 2 peer also doesn't work and you need a TURN server to relay the video.