Some beginner questions on Kurento
127 views
Skip to first unread message
Kaiduan Xie
Apr 3, 2023, 5:13:58 PM4/3/23
to kurento
Hi,
I started playing around the Kurento server and found out it is quite cool!
I have some questions as a beginner.
1. Is it a SFU or MCU?
I looked the tutorial code for group call and broadcast call below
and
the above code just connects sender's webrtc endpoint to receiver's webrtc endpoint. That is quite convenient from application developer's point of view.
Internally, does Kurento media server work as a SFU or MCU for above tutorial?
2. Can Kurento media server support big conference spanning on multiple Kurento media servers? If yes, how to support it?
Many thanks for the help,
/Kaiduan
Neil Young
Apr 4, 2023, 1:49:09 PM4/4/23
to kurento
To not let this unanswered: From the docs it can be both, MCU and SFU
Generally the dynamic in this project tends to 0, even though some (the?) developer(s) are very engaged. Answers come weeks later, if they come. But they are always founded, though. I wouldn't recommend to use KMS anymore. Meanwhile I made the turn to mediasoup, which seem to have a brighter future. This is not meant offensive, it is a matter of fact. KMS has seen version 7 and there will be no major development happen. Things like simulcast or so will never land in KMS.
I personally never have used MCU functionality. SFU works. Not sure how it scales. I also never have used KMS in many-to-many situations. For this maybe Jitsi or Janus are better.
Generally the dynamic in this project tends to 0, even though some (the?) developer(s) are very engaged. Answers come weeks later, if they come. But they are always founded, though. I wouldn't recommend to use KMS anymore. Meanwhile I made the turn to mediasoup, which seem to have a brighter future. This is not meant offensive, it is a matter of fact. KMS has seen version 7 and there will be no major development happen. Things like simulcast or so will never land in KMS.
If you need OpenCV or GStreamer processing server-side, then KMS is a MUST, since there is no other media server out there.
Juan Navarro
Apr 4, 2023, 2:18:35 PM4/4/23
to kur...@googlegroups.com
As a matter of fact, I agree with the summary written by Neil.
Kurento moved early on to an Apache 2.0 license with hopes of becoming a community project where not only the original team but also other big players maybe contributed together. This never happened and the project failed to get inertia.
Kurento is deep inside nothing more than a glorified manager of pretty complex GStreamer pipelines, and tries to empower users to create any kind of construct they want, but that comes with the price of a high complexity that needs resources ($$$) that are not there in the market. Right now, its maintenance is being paid for the needs and features used by the OpenVidu project, which by the way is able to abstract away whether Kurento or Mediasoup are used as WebRTC SFU media servers.
Kurento is mainly an SFU because it is natural to connect one source (e.g. WebRtcEndpoint) to N sinks, individually. However, it is able to act as a MCU because it has something called Composite that is able to mix several videos into a single one. I wouldn't recommend using it, though; in general, for WebRTC, the SFU model seems to have won as it is much more flexible and requires less powerful machines (can directly transmit the source video to the sinks).
Speaking of resource usage: one thing that Kurento can do and mediasoup cannot (and not sure about other servers) is to adapt between incompatible codecs. You can load up a video file (or an RTSP stream from wherever) that was recorded in any random format, and Kurento will transcode it to VP8 or H.264 so other WebRTC consumers will accept it. Other servers, well, if the source media is not already in the appropriate encoding, they don't help you with that. As a result, people tend to reinvent the wheel with custom localhost-based RTP exchange between mediasoup and FFmpeg, where FFmpeg does the transcoding.
Lastly, Kurento is a very low level tool. It's like going for FFmpeg when what you want is to make a DVD movie. For people who want to *make an actual WebRTC-based product*, as opposed to tinkering endlessly with the thousand paper cuts of the WebRTC standard, I'd recommend to go with OpenVidu instead. It uses Kurento behind the scenes, and also offers an upgrade path with mediasoup when some needs grow and Kurento is not enough any more.
Cheers
Kurento moved early on to an Apache 2.0 license with hopes of becoming a community project where not only the original team but also other big players maybe contributed together. This never happened and the project failed to get inertia.
Kurento is deep inside nothing more than a glorified manager of pretty complex GStreamer pipelines, and tries to empower users to create any kind of construct they want, but that comes with the price of a high complexity that needs resources ($$$) that are not there in the market. Right now, its maintenance is being paid for the needs and features used by the OpenVidu project, which by the way is able to abstract away whether Kurento or Mediasoup are used as WebRTC SFU media servers.
Kurento is mainly an SFU because it is natural to connect one source (e.g. WebRtcEndpoint) to N sinks, individually. However, it is able to act as a MCU because it has something called Composite that is able to mix several videos into a single one. I wouldn't recommend using it, though; in general, for WebRTC, the SFU model seems to have won as it is much more flexible and requires less powerful machines (can directly transmit the source video to the sinks).
Speaking of resource usage: one thing that Kurento can do and mediasoup cannot (and not sure about other servers) is to adapt between incompatible codecs. You can load up a video file (or an RTSP stream from wherever) that was recorded in any random format, and Kurento will transcode it to VP8 or H.264 so other WebRTC consumers will accept it. Other servers, well, if the source media is not already in the appropriate encoding, they don't help you with that. As a result, people tend to reinvent the wheel with custom localhost-based RTP exchange between mediasoup and FFmpeg, where FFmpeg does the transcoding.
Lastly, Kurento is a very low level tool. It's like going for FFmpeg when what you want is to make a DVD movie. For people who want to *make an actual WebRTC-based product*, as opposed to tinkering endlessly with the thousand paper cuts of the WebRTC standard, I'd recommend to go with OpenVidu instead. It uses Kurento behind the scenes, and also offers an upgrade path with mediasoup when some needs grow and Kurento is not enough any more.
Cheers
-- Juan Navarro Software Development Engineer Kurento & OpenVidu WebRTC platforms | https://openvidu.io/
--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/db01498f-30c7-41f8-8427-e83c7edc169fn%40googlegroups.com.
Neil Young
Apr 4, 2023, 2:25:07 PM4/4/23
to kurento
Thanks, Juan, for making that clear. As you know, I very much appreciate your work. But it is what it is finally.
I totally agree on the pros and cons you made. I was happy with KMS for years and I believe it would work for my use cases for "four more years" (if the setOutputBitrate thing would finally be fixed :)) But I also try to prevent to use transcoding as much as I can. In case of OpenCV plugins transcoding is mandatory, that's why I would really like to have that bitrate thing fixed. But this is not mandatory at all.
Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
0 new messages