Recommend 250 Mbits/sec bandwidth

400 views
Skip to first unread message

Fred Dixon

unread,
May 14, 2019, 9:36:57 PM5/14/19
to BigBlueButton-dev
Hi Everyone,

For years we've been recommending servers with 100 Mbits/sec symmetrical bandwidth.

With the release of the HTML5 client and using WebRTC (not Flash) for the video streams, we can see as users share many webcams (i.e. 20 users in a session all sharing webcams), it's possible to saturate a 100 Mbits/sec connection.

To support use cases where many users want to share their webcams, we are revising our server recommendations to 250 Mbits/sec.  Most servers have Gigabit internet connections.  

It is possible to significantly reduce the bandwidth by having a moderator engage the Lock Settings to restrict viewers to only see the moderator's webcam.  

For example, with 20 people in a session share their webcam, it will, by default, create 400 streams: 20 going into the BigBlueButton server and 380 coming out.

If the Lock Settings to restrict viewers to only see the moderator's webcam is in effect, and there is only one moderator in the session, then the same scenario will have 39 streams: 20 going into the server and 19 coming back (for the moderator).


Regards,... Fred
--
BigBlueButton Developer
@bigbluebutton

Phill. Whiteside

unread,
May 15, 2019, 5:01:37 AM5/15/19
to bigblueb...@googlegroups.com
Hi Fred,

thanks for the update. So, if one moderator is solely sharing his web cam for, say, 100 students, would using flash and not HTML5 have a massive impact on bandwidth usage?

Regards,
Phill.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/CAOeuy5OXd%3DTjF5FBMBya5Gg-j0s9eYLo1jCMYw9kyN29tdgZPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fred Dixon

unread,
May 15, 2019, 6:41:34 AM5/15/19
to BigBlueButton-dev
Hi Puil,


> thanks for the update. So, if one moderator is solely sharing his web cam for, say, 100 students, would using flash and not HTML5 have a massive impact on bandwidth usage?

With 100 students and one moderator sharing webcam, you should be fine with both Flash and HTML5.  The extra bandwidth would give you headroom if a few more students in a 100 webcam session start sharing their webcam.   As well, in such sessions, a moderator can always lock down viewers from sharing their webcam using the Lock Settings.

You can prevent viewers from sharing webcams altogether, and you can prevent viewers from seeing other viewer's webcams.

image.png

Regards,... Fred


For more options, visit https://groups.google.com/d/optout.

Walter Tak

unread,
May 15, 2019, 7:30:05 AM5/15/19
to bigblueb...@googlegroups.com
Suggestion ; besides turning on/off viewer webcams you can limit their FPS to say 1 or even 0.1 ; so they'd still have 'faces' which do update but very slowly which reduces bandwidth and load on the server by at least factor 20 (1 fps) to 200 (0.1 fps). The quality can be higher so the small thumbnail will look good too. A small slider to set viewer webcam FPS between 0.1 and 20 would be nice.

jossef

unread,
May 15, 2019, 9:08:50 AM5/15/19
to BigBlueButton-dev
Hi Fred
on Flash i use high key Frame Interval and low FPS to Connect lots of cameras.
is there an option somewhere to set html5 video's Fps and key Frame Interval ?

בתאריך יום רביעי, 15 במאי 2019 בשעה 14:30:05 UTC+3, מאת Walter Tak:
To unsubscribe from this group and stop receiving emails from it, send an email to bigblueb...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigblueb...@googlegroups.com.


--
BigBlueButton Developer
@bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigblueb...@googlegroups.com.

Chad Pilkey

unread,
May 15, 2019, 1:55:39 PM5/15/19
to BigBlueButton-dev
I don't know about the key frame interval, but the fps of the camera is uncapped for now. I want to set similar limits to what we had in the Flash client though.

Paulo R. Lanzarin

unread,
May 15, 2019, 2:01:41 PM5/15/19
to bigblueb...@googlegroups.com
is there an option somewhere to set html5 video's Fps and key Frame Interval ?
You cannot set the keyframe interval/gop size because the WebRTC stack built in the browsers
do not expose that configuration yet. The keyframe interval is pretty well regulated, tho. They should
only be sent for new subscribers or for full intraframe refreshes requested on unrecoverable losses.

Regarding FPS, it's what Chad said, uncapped. What matters is the bitrate, and that has a hard cap of 300kbps
for cameras and 1500kbps for screenshare, tho, and they might go lower than that according to the bitrate estimation algorithm.
Lowering the bitrate is up to the browser and they usually lower both FPS and resolution dynamically.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.

To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.

jossef

unread,
May 15, 2019, 5:01:32 PM5/15/19
to BigBlueButton-dev
Thanks for the explanation.
It is important for me not to go over about 90kbps per video.
I'm currently running a number of parallel flash classes, with about 15 video each. 
I get a very reasonable video quality, with 160X120 resolution, and 10FPS.
When you add control over bandwidth limits in the future, I will be happy to provide feedback on Performance in this use case.
Apparently, in the meantime, I will have to stick with the flash client.




בתאריך יום רביעי, 15 במאי 2019 בשעה 04:36:57 UTC+3, מאת Fred Dixon:

Fred Dixon

unread,
May 15, 2019, 5:11:03 PM5/15/19
to BigBlueButton-dev
Hi Jossef,

> Apparently, in the meantime, I will have to stick with the flash client.

It's is our goal to make the HTML5 client good enough so you can move your classes over to it.  You've been using the Flash client for many years -- and giving us great feedback.  Hopefully we can get you on to the HTML5 client (and to a better experience) with your users.

Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.

For more options, visit https://groups.google.com/d/optout.

Chad Pilkey

unread,
May 15, 2019, 5:34:55 PM5/15/19
to BigBlueButton-dev
The unfortunate part with WebRTC is that there are quite a few actors that have their own ideas of what an ideal use case is and then individual ways of trying to accomplish that. On top of that the browser manufactures try and get fancy and max out the local user's upload speeds. This demo shows a pretty good example of what I'm talking about, https://webrtc.github.io/samples/src/content/peerconnection/constraints/. I can set video dimensions to 160x120 and 10 fps and it will fluctuate between 100 and 550 kbits/sec. The only way to put bandwidth caps is by munging the SDP that the client offers and then also munging the SDP that the server answers with. They don't make it easy. We're also using VP8 now instead of H264 and if this site (https://www.webrtc-experiment.com/webrtcpedia/) is to be believed then the minimum bandwidth for a video stream is 100kbits/s.

Paulo R. Lanzarin

unread,
May 15, 2019, 5:50:04 PM5/15/19
to bigblueb...@googlegroups.com
Jossef,

You can set the hard bitrate cap for cameras/screenshare to whatever value you wish and try it out. I don't believe
you'll get to 90kpbs, but 100kbps might work.
Just alter the values for `tias_content`/`as_content` (screenshare) and `tias_main`/`as_main` in bbb-webrtc-sfu's config
file (/usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml) to whatever value you wish, restart the component 
(sudo systemctl restart bbb-webrtc-sfu) and try it out. This does automatic mangling of both client and server SDPs
and shoudl tell the browser what the hard limit is. Hopefully you can find some value that works somehow well for your
use case.

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.

jossef

unread,
May 16, 2019, 11:09:45 AM5/16/19
to BigBlueButton-dev
Hi Fred.
The Html5 client is definitely far better, I will use it as soon as possible on other classes.
Actually, on the link Chad sent, (Thank's Chad) I produce nice video with an average BW of 60 kbps. (120X80 3FPS).
It sounds like it's a bad video, but it's not, it's enough for the teacher to see the student is currently in front of the computer, the small Resolution looks ok since with 15 open windows each individual video window is small anyway. 
( i also checked setting hard bit-rate cap and received frozen video on Flash and WebRTC)
So, once you guys allow control over resolution and fps, it will open the plug to all users in the world who do not have enough bandwidth.
I have noticed over the years that there is nothing too difficult for bigbluebutton dev team.
That's why now I'm optimistic that eventually the webrtc video will be great for all my classes.
Regards,...Jossef




בתאריך יום רביעי, 15 במאי 2019 בשעה 04:36:57 UTC+3, מאת Fred Dixon:
Hi Everyone,

Chad Pilkey

unread,
May 16, 2019, 1:07:45 PM5/16/19
to BigBlueButton-dev
You can actually set the resolutions and fps in beta7 now, but it only works if the browsers obey it which they don't always do. Apple is particularly troublesome and often won't allow smaller resolutions.

Another neat WebRTC demo page is this one, https://webrtchacks.github.io/WebRTC-Camera-Resolution/. I will do the Quick Scan option with different cameras and devices to see what they will accept.

jossef

unread,
May 17, 2019, 4:41:19 AM5/17/19
to BigBlueButton-dev
Hi Chad
 >>> You can actually set the resolutions and fps in beta7 now, 

I've just installed beta7.
i see where to change resolutions but where Can i find where to change fps ?






בתאריך יום חמישי, 16 במאי 2019 בשעה 20:07:45 UTC+3, מאת Chad Pilkey:

Chad Pilkey

unread,
May 17, 2019, 1:13:40 PM5/17/19
to BigBlueButton-dev
The "constraints" section in each profile is taken literally and passed to the browser as restrictions for the profile so you can add any restrictions found here, https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints#Properties_of_video_tracks. For some of them you can set min, max, ideal, and/or exact, but not all browsers will obey them. We use height.max and instead of height.exact because the former is more permissive and will allow devices that will only match widescreen resolutions. To set fps you should be able to add "fps: 10" to the constraints of a profile and then restart bbb-html5 to have it take effect.

jossef

unread,
May 18, 2019, 10:15:12 AM5/18/19
to BigBlueButton-dev

It turned out that my previous testing was not good. i tested again according to Paulo's advice with 100kbps hard bit-rate cap, this time video was ok with average 60kbps output.
so it's problem solved for me :) 

regarding fps / frameRate constraint: 
did not affect chrome in any Syntax option i used in settings.yml.
however.. on old server with 2.0.0-rc7 version,  the chrome did obey when i added
"frameRate": { "exact": 2 }   in  settings-prodution.json.

thank's again for all your help
Jossef



בתאריך יום שישי, 17 במאי 2019 בשעה 20:13:40 UTC+3, מאת Chad Pilkey:

Fung

unread,
May 18, 2019, 11:42:24 PM5/18/19
to BigBlueButton-dev

said

We'll pick up the deployment of BigBlueButton components via a CDN in 2.2.

any documents about this?


Alex Ejov

unread,
May 21, 2019, 6:15:49 AM5/21/19
to BigBlueButton-dev

if we have a speed of 20 megabits. it may just be that the webcam is only from the moderator, and in 30-40 minutes the webcam just crashes. why it happens?

среда, 15 мая 2019 г., 4:36:57 UTC+3 пользователь Fred Dixon написал:

Fred Dixon

unread,
May 21, 2019, 6:52:12 AM5/21/19
to BigBlueButton-dev
Hi Alex,

> if we have a speed of 20 megabits. it may just be that the webcam is only from the moderator, and in 30-40 minutes the webcam just crashes. why it happens?

Can you reproduce this on 


Regards,... Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.

For more options, visit https://groups.google.com/d/optout.

Alex Ejov

unread,
May 21, 2019, 7:22:22 AM5/21/19
to BigBlueButton-dev
Hi Fred. its problem we can see on our server. on your server we couldn't find out this problem

вторник, 21 мая 2019 г., 13:52:12 UTC+3 пользователь Fred Dixon написал:
Hi Alex,

> if we have a speed of 20 megabits. it may just be that the webcam is only from the moderator, and in 30-40 minutes the webcam just crashes. why it happens?

Can you reproduce this on 


Regards,... Fred

On Tue, May 21, 2019 at 6:15 AM Alex Ejov <lesh...@gmail.com> wrote:

if we have a speed of 20 megabits. it may just be that the webcam is only from the moderator, and in 30-40 minutes the webcam just crashes. why it happens?

среда, 15 мая 2019 г., 4:36:57 UTC+3 пользователь Fred Dixon написал:
Hi Everyone,

For years we've been recommending servers with 100 Mbits/sec symmetrical bandwidth.

With the release of the HTML5 client and using WebRTC (not Flash) for the video streams, we can see as users share many webcams (i.e. 20 users in a session all sharing webcams), it's possible to saturate a 100 Mbits/sec connection.

To support use cases where many users want to share their webcams, we are revising our server recommendations to 250 Mbits/sec.  Most servers have Gigabit internet connections.  

It is possible to significantly reduce the bandwidth by having a moderator engage the Lock Settings to restrict viewers to only see the moderator's webcam.  

For example, with 20 people in a session share their webcam, it will, by default, create 400 streams: 20 going into the BigBlueButton server and 380 coming out.

If the Lock Settings to restrict viewers to only see the moderator's webcam is in effect, and there is only one moderator in the session, then the same scenario will have 39 streams: 20 going into the server and 19 coming back (for the moderator).


Regards,... Fred
--
BigBlueButton Developer
@bigbluebutton

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigblueb...@googlegroups.com.

Phill. Whiteside

unread,
May 21, 2019, 3:17:50 PM5/21/19
to bigblueb...@googlegroups.com
Hi Alex,

I've got a BBB in test mode, so all the demos are available. It is basic (old) BBB specs with 4 core, 4GB of RAM and on 100Mb/s link. You're welcome to do some testing on it. It is running the latest 2.2-beta8. https://faircam.net is the URL

Hope that helps you work out if the issue is resources on your server, or a mis-configuration

Regards,
Phill.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.

To post to this group, send email to bigblueb...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-dev.

Walter Tak

unread,
May 21, 2019, 5:39:35 PM5/21/19
to bigblueb...@googlegroups.com
Make graphs of CPU and memory usage. Use RRDTOOL or another modern way to collect, save and graph data so you can see in the graphs WHEN the server crashed. Perhaps there was a CPU spike on a car, perhaps a process ran out of memory. Perhaps there were a ton of connections.

Without statistics or very clear error logs of the crash it is hard to debug. Try another server, update your OS, check all your logs, simulate the scenario where
the server crashes for example by overloading it (too many users, too many webcams etc) and see where it goes wrong.



Reply all
Reply to author
Forward
0 new messages