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.

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.

Kurento is not dead. Main contributions are on OpenVidu project, that somehow is part of Kurento (but with other name)

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/

Of course, this means that you must build your application, including UI, client-server signaling, etc etc.

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

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.

PornHub uses mediasoup for live cams.

That’s quite the endorsement.

exactly what I was thinking :)

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.