jitsi / lib-jitsi-meet

A low-level JS video API that allows adding a completely custom video experience to web apps.
Apache License 2.0
1.34k stars 1.11k forks source link

congestion control mechanism #681

Open stanal opened 6 years ago

stanal commented 6 years ago

Hi,I want to know does this lib support some end-to-end congestion control mechanism,such as the GCC congestion control which has been implemented in webrtc ? Hope your reply. thx.

bgrozev commented 6 years ago

This project is a javascript library and doesn't implement congestion control. However, the java library libjitsi implements GCC (and jitsi-videobridge uses it).

stanal commented 6 years ago

ok, thanks, But, how can I use libjitsi with jitsi-videobridge and jitsi-cofo to build an video conference application just like what jitsi-meet do? There is no cookbook likely documents for lib-jitsi,so I'm too confused to use the libjitsi.

saghul commented 6 years ago

@stanal You can build atop this library (lib-jitsi-meet), which takes care of all of that. There is in-deep document describing all the interactions, so maybe try to be more specific about what you're interested in and we'll try to help you out!

stanal commented 6 years ago

Ok, I know about the jitsi-meet which is built based on the lib-jitsi-meet that also be used in the android version of jitsi-meet. But I also want to know what means does this library use to control the bitrate of sending the media data between two peers , and where can I find the bitrate control module in this library, or the module that control the rate of the video decoder ? Besides, does this library(lib-jitsi-meet) built atop the libjitsi, or is there any relation between these two libraries, or what's the main goal of them in respectively ? Thanks.

saghul commented 6 years ago

Ok, I know about the jitsi-meet which is built based on the lib-jitsi-meet that also be used in the android version of jitsi-meet.

That's correct.

But I also want to know what means does this library use to control the bitrate of sending the media data between two peers , and where can I find the bitrate control module in this library, or the module that control the rate of the video decoder ?

This library handles signaling so endpoints can join the conference. Media will flow between your browser (or mobile app) and the Jitsi videobridge. The jvb does bandwidth estimation, but there is nothing to tune in the library, maybe @gpolitis can guide you through the internals in the jvb though.

Besides, does this library(lib-jitsi-meet) built atop the libjitsi, or is there any relation between these two libraries, or what's the main goal of them in respectively ?

No, they are not related. lib-jitsi-meet is a JS library which implements a (relatively) low level API for singling an WebRTC stream handling. libjitsi, is a Java library which implements different SIP/XMPP signaling and RTP media features which are shared amongst Jitsi (the desktop client), jigasi and jvb.

stanal commented 6 years ago

This library handles signaling so endpoints can join the conference. Media will flow between your browser (or mobile app) and the Jitsi videobridge. The jvb does bandwidth estimation, but there is nothing to tune in the library, maybe @gpolitis can guide you through the internals in the jvb though.

You mean the jitsi-meet peer transmit its media data to jvb server and then the jvb server forward the media data to another peer?

But, I know the jitsi-meet use P2P model when there are only two participates which means that the media data should not flow through the jvb server, so how the jvb server control the bandwidth between the two peer?

saghul commented 6 years ago

You mean the jitsi-meet peer transmit its media data to jvb server and then the jvb server forward the media data to another peer?

Yes.

But, I know the jitsi-meet use P2P model when there are only two participates which means that the media data should not flow through the jvb server, so how the jvb server control the bandwidth between the two peer?

When there are only 2 participants in a conference, we indeed attempt to establish a P2P connection. In that case bandwidth estimation is done between the 2 browsers, using GCC or the newer server-side bandwidth estimation. This post has a nice overview: http://www.rtcbits.com/2017/01/bandwidth-estimation-in-webrtc-and-new.html

stanal commented 6 years ago

I check my jvb server just now, I find that the bitrate of into the server is 1300kbps,but the out bitrate from the server is only 350kbps, the into bitrate is all the time larger than out bitrate.

About the two peers (two android devices), I find that the transmission of media data which produced by device A and sended to device B has almost no delay. But, the media data transmission sended from device B to device A not only has large delay but also closed occasionally on device A along with a prompt "...has been turned off to save bandwidth." showed on the device A surfaceview.

Does this means that device A sends its media data directly to device B so that B has little delay with its received video data, and the device B use jvb server to forward its media data to device A , because of the low bandwidth of server, device A has low quality of its received video data ?

saghul commented 6 years ago

I check my jvb server just now, I find that the bitrate of into the server is 1300kbps,but the out bitrate from the server is only 350kbps, the into bitrate is all the time larger than out bitrate.

This is expected, to some extent. We use simulcast, which means a sender may send up to 3 video encodings, and the server will only forward the appropriate one.

About the two peers (two android devices), I find that the transmission of media data which produced by device A and sended to device B has almost no delay. But, the media data transmission sended from device B to device A not only has large delay but also closed occasionally on device A along with a prompt "...has been turned off to save bandwidth." showed on the device A surfaceview.

If they are both on the same WiFi, they'll likely use P2P (alas there is no way to check this on mobile) so there should be no delay. Now, it's possible device B is overwhelmed (is it an old phone or a reasonably recent one?) and thus has a hard time decoding the received video data. This will end up resulting in video being disabled.

Does this means that device A sends its media data directly to device B so that B has little delay with its received video data, and the device B use jvb server to forward its media data to device A , because of the low bandwidth of server, device A has low quality of its received video data ?

No, that's not possible, they either use P2P or the jvb, not a mix.