
Mediasoup – WebRTC video conferencing - simonpure
https://github.com/versatica/mediasoup
======
goroutine
How does mediasoup compare Pion project in terms advantages, performance and
effort to build a simple conference app? Why I choose one over the other?

------
throwawaybbqed
I've looked at WebRTC a few times, and every time I've been overwhelmed by the
complexity of the protocol. I understand video streaming is hampered by codec
patents, etc. but in 2020, the situation seems to be getting better with open
source codecs unencumbered of patents (VP8,VP9, AV1, etc.) Why is the best we
have still WebRTC? Seems it could be simplified as a protocol .. is this
inherently hard or just a result of being designed in a committee?

~~~
algesten
It's way too complicated. I suspect it's some design by committee with large
backer interests interfering.

WebRTC is a collection of underlying protocols, SDP, STUN, DTLS, RTP, SCTP. A
superficial glance it seems to make sense, each of these RFCs provide some
aspect needed in WebRTC.

However. These standards are from a naive happy time when the internet was
open and routable, which means it's only some subset of said standards needed.
The main WebRTC RFC fails at pinning down which, so it's down to the
implementations to find some happy subset that works.

Trying to implement it is so frustrating. At every corner you follow links to
some underlying RFC, start reading and coding only to realize "is this even
used?!"

SDP is maybe the single worst thing in this mess. It's a terrible flat file
description of structured data organized differently depending on "plan-b" or
"unified". It would be super easy to convey what SDP tries to convey in any
purpose built format.

On a conceptual level there are too many abstractions in the API. MediaStream
and RTPTransceiver are my two pet peeves. MediaStream is maybe nice in client
code to group some tracks together into a player, but the abstraction should
stay on that level. RTPTransceiver is just beyond me. Why do I want it? How
does this help?

~~~
Sean-Der
It looks like RIPT[0] is people's answer to WebRTC's complexity.

I personally like WebRTC. Maybe just Stockholm syndrome though :) I see
everyone saying QUIC is the answer, but all the complexity scares me. I
imagine in 5 years everyone will miss how WebRTC is built with small building
blocks.

WebRTC also bridges with a lot existing telephony stuff, which is nice! Since
it talks RTP/SRTP I see a lot of people wiring it up to their older systems
which is kind of cool!

[0] [https://tools.ietf.org/html/draft-rosenbergjennings-
dispatch...](https://tools.ietf.org/html/draft-rosenbergjennings-dispatch-
ript-00)

------
webel0
Can someone explain how mediasoup differs from the RTCPeerConnection object
(and related events) discussed in this Mozilla webrtc tutorial [0]? Given that
it uses c++ I figure that mediasoup is more than just a wrapper around this?
Any usability or reliability benefits of either?

[0] [https://developer.mozilla.org/en-
US/docs/Web/API/WebRTC_API/...](https://developer.mozilla.org/en-
US/docs/Web/API/WebRTC_API/Signaling_and_video_calling)

~~~
ibc
mediasoup (server side, so the Node + C++ component you mean) does not
implement "RTCPeerConnection". That's just needed for browsers. In mediasoup
we don't use SDP but specific RTP parameters as defined here:

[https://mediasoup.org/documentation/v3/mediasoup/rtp-
paramet...](https://mediasoup.org/documentation/v3/mediasoup/rtp-parameters-
and-capabilities/)

If you want to know why we don't use SDP (as communication means between
client and server) here a good reading: [https://webrtchacks.com/webrtc-sdp-
inaki-baz-castillo/](https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/)

~~~
webel0
Ah, okay, whenever I think webrtc I assume p2p with no server but I am now
actually reading into what SFU is, etc. Makes sense. Thanks for pointer to
these resources.

------
monkeydust
What kind of hardware would I need to setup this to run a private video chat
server for say 10 users?

~~~
Recursing
What advantages would this offer over jitsi meet?

~~~
kabes
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
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.

------
andrethegiant
You can use WebRTC for emitting raw data p2p, not just audio/video streams,
right? Or would websockets be preferred if you wanted to, say, broadcast JSON
objects to whoever was listening?

~~~
ibc
Yes, you can use WebRTC DataChannels for sending custom text/binary data on
top of a ICE+DTLS connection. BTW mediasoup supports DataChannels.

Any question or comment about mediasoup?

~~~
andrethegiant
What advantages does sending data over WebRTC have over sending data over
websockets?

~~~
ibc
DataChannels are transmitted over the same UDP/ICE "connection" that is used
to transmit audio and video packets. So if you plan to send real-time data
(for example: real-time subtitles, metadata related to the current video
position, etc) by sending such a data over DataChannel it will reach the
remote without delay over the audio/video. If you use WebSocket to transmit
the data, there may desynchronization between audio/video and data because
they use a different network path.

------
telesilla
The demo is nice and clean. How does this compare to Kurento, or Janus?

Edit : I see Kurento is now assumed dead thanks to Twilio buying them, and I
understand Janus doesn't provide any client libraries.

~~~
micaelgallego
Kurento is not dead. New releases are published from time to time. And its
companion project OpenVidu provides a lot of features. Mediasoup and Janus are
also really good projects.

Disclaimer: I'm OpenVidu project lead.

~~~
stragies
Is there a specific reason hindering you from publishing a Debian package, or
becoming/appointing a Debian packager, so that your product is available to
anyone restricted to official package Debian sources?

~~~
navanchauhan
Anyone can be a Debian package manager and publish their package in their PPA
repository, mediasoup is a Node.js library, think of it as another NPM
dependency for your project

------
tomasyany
Has anybody compared MediaSoup with Kurento?
[https://www.kurento.org/](https://www.kurento.org/)

~~~
kabes
The team behind kurento got hired by twilio some years ago. Now it's basically
dead with some very minimal maintenance being done.

~~~
tomasyany
I was asking about differences in the features they support, and results in
real life experiences.

Also, I don't agree with Kurento being dead (off topic, but hey). It is still
being maintained and works perfectly well for modern applications.

------
Snelius
It's a best we have as wrtc SFU today. Thank you guys.

