Hi,
on our Android solution we use high quality settings for video streaming, for example H264 Full HD 30 fps, but the bandwidth always remains around 350 KBytes / s. Even with different resolutions and different fps. The band does not exceed the threshold. Do you know if inside Kurento there is a limit somewhere?
These parameters in /opt/openvidu/.env file are related with bandwith limitation and Kurento:
OPENVIDU_STREAMS_VIDEO_MAX_RECV_BANDWIDTHOPENVIDU_STREAMS_VIDEO_MIN_RECV_BANDWIDTHOPENVIDU_STREAMS_VIDEO_MAX_SEND_BANDWIDTHOPENVIDU_STREAMS_VIDEO_MIN_SEND_BANDWIDTH
You can check more info about these parameters here:
https://docs.openvidu.io/en/stable/reference-docs/openvidu-config/#configuration-parameters-for-openvidu-ce
Yes I know that settings and I have tried upper and lower value. No changes. I will continue to look at WebRTC source code to find why the bitrate is low.
Kurento has one big limitation with bandwidth: the worst Subscriber connection will condition the rest of Subscriber connections. This is due to the inner negotiation of available bandwidth that happens between the Publisher and its Subscribers. The Publisher will adapt its bandwidth to what the worst of the Subscribers state they can handle, and this will also affect the rest of the Subscribers.
To overcome this, other media servers implement simulcast and svc. In OpenVidu we recently opened the beta for the Enteprise tier (free while in beta), which supports mediasoup and simulcast: Simulcast - OpenVidu Docs
@pabloFuente If you say “Kurento” that would mean that this also has an impact to applications which utillize the KMS directly, w/o OpenVidu?
Given this scenario: Having a WebRTC sendonly source, full HD, 30 fps, 3MBit/s encoding bandwidth. You say there can be a situation, in which say 5 “viewers” (separately negotiated recvonly connections) will finally agree on the lowest bandwidth which satisfies the lamest of the 5? So 4 Gigabit viewers would suffer from one ISDN user? (if ISDN is still in use somewhere)
That’s exactly right. And yes, that is a Kurento limitation. Implementing simulcast / SVC is the solution. Other media servers do so.
Thanks. Which other media server do you mean, for instance?
I’m wondering if the simulcast support will also land in KMS. Will it?
Hello @Neil_Young
mediasoup supports simulcast.
You can use mediasoup in OpenVidu Enterprise.
We do not expect to have simulcast implemented in Kurento in the near future.
Regards
Thanks for the answer. That’s too bad. I’m having no need for OpenVidu, was always happy with KMS. But this limitation forces me to switch to other things… Hmmm
@micael.gallego Sorry, I need to ask again, before making premature decisions. I think you once answered me the question with “yes”, whether I could use the low level interface of KMS (provide an offer, get an answer, same with candidates and stuff) in a node app (as I’m currently able to do well).
Say you will somewhen have simulcast support in OpenVidu Enterprise, would that enable me to benefit from that, or is it all done above KMS in OpenVidu?
Thanks in advance
OK, I have verified the statement from @pabloFuente and here is my observation:
- Setup:
- KMS plus Node proxy server running in a VM
- Signaling server on the same machine
- Python script, using GStreamer to capture H.264 from a capable USB camera and offer H.264 only, 1280x720, baseline, 30 fps
- Client web app on other machines:
- Making the Python script sending an OFFER to the KMS using the signaling server. KMS is answering to the Python script. Video flows from the Python script (GStreamer) to KMS (“sendonly”)
- Opening multiple other connections, now as “viewer”: Negotiating “recvonly” connections with KMS
- Line conditioner:
- One PC is running Apple’s Network Link Conditioner, which allows to set various profiles (LTE, Edge, 3G, DSL) on the network link to simulate outages and bandwidth shortage. Awesome tool, btw. It enables me do do the same, what is available in Chome (throttling), but what doesn’t work with UDP connections.
- Observations:
-
As long as the KMS is supporting VP8 and H.264 the agreement on the viewer side is always VP8, obviously a browser preference (since VP8 codecs are listed first). The observed encoding bitrate is about 500 k (need to check, why, maybe I did configure this in the past, I recall something like this).
-
When the machine, which has the “network conditioner” enables this the quality of the video in resolution and bitrate decreases on all viewers. On all machines is video, just bad. I had the impression, that on the non-disturbed machine it recovers after a while (especially when the slow machine gave up), but not sure
-
When I disable VP8 on the KMS by configuration, the video comes at 5 MBit/s from the camera, passes the KMS as is and is delivered to the viewers. The disturbed machine is just stuck (frozen video display, lot of NACKS and package losses). But all others are fine
Does that observation make sense? I think yes, because I suppose, in case of NOT transcoding the KMS is just forwarding the RTP as it comes, right?
Your observation seems ok. If there is transcoding in KMS, bitrate is reduced to server the user with worst connection. If there is no transcoding in KMS, the bitrate cannot be adapted.
OpenVidu Enterprise provides simulcast only when using mediasoup. Simulcast is not supported in KMS.
Regards
Thanks Micael, for the confirmation. Your last remark makes it clearer: I was wondering, how you want to achieve that w/o adapting KMS accordingly.
If you now bet on mediasoup, why don’t you retiring KMS?
mediasoup and KMS provides a different set of features.
We don’t consider that KMS is worse than mediasoup.
There are features available in KMS not available in mediasoup (RTSP, transcoding, computer vision filters, etc…).
There are features available in mediasoup not available in KMS (simulcast, VP9, reduced connection time, etc…).
You have to use the media server that better fits your needs.
Thanks, Micael. Very helpful. My problem is, that I’m forced to use the low level APIs of Kurento, since I’m not keen to create yet another video conferencing system out of the box. I have different sources of OFFERS and different sinks for ANSWERS, so far I didn’t have found another MS, which is so “non-optionated” as KMS is (well, Janus would work as 1:1 replacement, but they have such ugly code and interface requirements and I can’t stand the lead developer, but for instance they don’t have such great things like “generateOffer”).
So I wouldn’t know how to picture these requirements with an OpenVidu instance. Or I didn’t understand it yet, also possible…
With OpenVidu you can connect publishers with subscribers very easily.
An OpenVidu session is composed by participants. Every participant can publish, subscribe or both.
openvidu-browser SDK hide all the complexities of doing that, but if you take a look to the protocol
https://docs.openvidu.io/en/stable/developing/rpc/
(and inspect messages exchanged) you can implement your own SDK tailored for your needs.
Using OpenVidu protocol you will be able to use Kurento or Mediasoup under the hood.
Regards
Oh, that doesn’t look too bad. Similar (from an application view) to Janus videoRoom. But what I miss there and here: I can’t publish a video by making OpenVidu the OFFERER. What I have seen is, that I can publish by providing an OFFER. I have some client implementations out, which explicitly are waiting for incoming OFFERS to ANSWER, but being not able to provide OFFERS by itself. The “generateOffer” from KMS was very helpful here…
But thanks anyway for enlighten me. This is definitely worth a try. I think I will install a container in a test instance to see, how it works.
In order to use mediasoup it is important to know the way it works:
- A publisher has to provide the offer and mediasoup is able to generate an answer.
- A subscriber can only provide an answer to an offer generated by mediasoup.
With Kurento you can generate the offer in both clients (publishers and subscribers).
Regards