Bandwidth usage & webcam resolution

[npiqueras]

Hi all,

first of all congratulations the developers for the great project. I'm
starting with it and have some questions:

1) It's possible to increase the resolution of webcam for reach
"higher video definition"? what is the max resolution allowed to reach
a meeting with good quality? On what does it depend?

2) if it's possible to improve the video quality, how or where can be
configured?

3) What are the video+audio default bandwidth usage for one user in a
5-people meeting (320x240 each one)?

Nico

[Walter Tak]

1) currently you can select 320x240 or 640x480 which is good enough for
normal conferencing , after a while you don't mind low quality image anymore
since it's all about the meeting and voice

2) it's configured in the code so far so you cannot change it with a simple
config-file for example, no doubt this will change

3) roughly 30-50 kbytes/second per stream. If you have a room with 5 people
in it with 5 webcams then the fomula is:

Y = 30-50 Kbytes/sec ; let's assume 40 Kbytes/sec on average
W = amount of webcams that are streaming
U = amount of users that are watching

server incoming bandwidth: W * Y
server outgoing bandwidth: W * (U-1) * Y (minus one since a
broadcaster does not has to subscrive to his own stream)

So with 5 ppl in a room with 5 webcams streaming you'll have;

in: 5 x 40 = 200 Kbytes/sec incoming bandwidth needed to the server (e.g.
1.6 Mbit)
out: 5 * (5-1) * 40 = 800 Kbytes/sec incoming bandwidth needed from the
server (e.g. 6.4 Mbit)

Total traffic used after one our: 60 mins x 60 secs x (200 + 800) = 3.6
Gbyte traffic per hour

If you'd have a typical "classroom" situation with 1 stream going to 30
students in a remote learning environment:

in: 1 x 40 = 40 Kbytes/sec incoming (e.g. 0.32 Mbit/sec)
out: 1 * (30-1) * 40 = 1160 Kbytes/sec outgoing (e.g. 9.3 Mbit/sec)

Total traffic used after one hour: 60 mins x 60 secs x ( 40 + 1160) = 4.3
Gbyte traffic per hour

If you'd have 10 of those classes then you server need to be able to output
93 Mbit/sec ; that's not much in a LAN but it's pretty much if you need to
hire a server.

Large "cafe-style chatroom" : 20 viewers, 8 people broadcasting with a
webcam:

in: 8 x 40 = 320 kbyte/sec ( 2.5 Mbit )
out: 8 * (20-1) * 40 = 6080 kbytes/sec ( 48.6 Mbit )

Total traffic used after one hour: 60 mins x 60 secs x ( 320 + 6080 ) = 23
Gbyte traffic per hour

Regards,
Walter

> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/bigbluebutton-dev?hl=en.
>

[npiqueras]

Thanks a lot Walter, very useful!

Regards,

Nico

[207me.com]

Walter this is a great explanation of video impacts on bandwidth...
Do you have an estimate for the bandwidth utilization of a desktop
sharing... I understand it will vary depending on the amount of screen
change..

I'm looking at placing a rack of 6 bbb servers behind my mikrotik core
router, and setting up some custom queues to prioritize the different
streams. I have 40mb/40mb pipe to internet... and would want to make
sure the audio, and maybe the presenters video and desktop sharing got
priority, over the participants video..

Have you looked at any of this prioritization within the
application? The particpants video streams would be throttled to 1
fps or slower when the link approaches saturation... but the presenter
would get top priority on his video,audio, and desktop sharing.

Goal would be to manage the bandwidth to eliminate a bad user
experience by tagging the presenter packets.

Stephen

> > >http://groups.google.com/group/bigbluebutton-dev?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Walter Tak]

Just see a desktopsharing connection as one webcam with a very high
bandwidth usage like 500 Kbytes per frame.

The huge size is due to, afaik, the very inefficient codec Screen Video
Bitstream that's unfortunately also the only codec in Flash that supports
this kind of desktopsharing.

That's why it takes quite a while before a frame is transferred from a
client to the server and from server to all viewers.

E.g. in a room with 20 viewers the formula for outgoing bandwidth , just for
desktopsharing could be:

server outgoing bandwidth: W * (U-1) * Y (minus one since a broadcaster does
not has to subscrive to his own stream)

1 * (20-1) * 500 = 9500 kbytes = 76 Mbit.

However these are peaks and the 9500 kbytes is ofcourse spread over a period
of say 30 seconds;
a desktop that's stable and is not changing at the presenter will not keep
sending data to the server like a webcam will.

Prioritizing MIGHT be possible by using QoS (quality of service) on port
9123 of desktopsharing but I'm not sure if all bits of desktopsharing
are going over 9123 ; perhaps Fred or Richard can comment on that.

If you're a bit familiar with token-buckets and traffic-shaping then you
might be able to shape the traffic and allow little burst per connected user
but in the end limit their bandwidth usage to say an average of 75 kbytes ;
that way you prevent some people to "push away / block / interfere" the
streams of others.

If you happen to be a smart guy that knows a bit about QoS and HTB / token
buckets en qdiscs then don't hesistate and check out this script that
someone used to give absolute priority to VoiP traffic, something we'd also
want on a BBB server where audio+video+deskstopsharing+http traffic
currently is competing with eachother:
http://www.voip-info.org/wiki/view/QoS+with+Linux+using+PRIO+and+HTB

I've played with traffic-shaping a while ago to reduce outgoing or incoming
bandwidth to a server (to prevent the server going over a certain amount of
mbit/sec) but that was interface-based not port based. I'll have a look at
it since port-based traffic shaping would be very nice for example to
prevent the interruption of video/audio of all connected users when a new
user connects and has to download a few megabytes of SWF files.

[207me.com]

Walter, thanks for the detail writeup, on this... i will investigate
the streams with wireshark and look at setting up some rules on
mikrotik using mangle and queueing by protocol or ports...

will report back to the group on my findings and try to
document.....we can set limits and bursting for each queue,,

stephen

> > > >http://groups.google.com/group/bigbluebutton-dev?hl=en.-Hide quoted

> > > >text -
>
> > - Show quoted text -
>
> --
> You received this message because you are subscribed to the Google Groups
> "BigBlueButton-dev" group.
> To post to this group, send email to bigblueb...@googlegroups.com.
> To unsubscribe from this group, send email to
> bigbluebutton-...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/bigbluebutton-dev?hl=en.- Hide quoted text -

[Walter Tak]

fyi I nearly forgot the mangle table and found a nice example (old, but
useful) for other people who might want to experiment with prioritizing VoiP
traffic:

http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO/lartc.cookbook.interactive-prio.html

[Pccom Frank]

Can someone help to offer a 80x60 tiny webcam size option for kids and poor men? Instead of increasing the band width, I am thinking to reduce the traffic.

[Fred Dixon]

Hi Frank,

The profiles for webcams options are in 

  /var/www/bigbluebutton/client/conf/profiles.xml

You can see them here

  https://github.com/bigbluebutton/bigbluebutton/blob/master/bigbluebutton-client/resources/prod/profiles.xml

You could create a profile called "very low" with 80x60 resloution by adding the following text.

      <profile id="very low">

        <locale>

            <en_US>Very Low quality</en_US>

            <pt_BR>Baixa qualidade</pt_BR>

        </locale>

        <width>80</width>

        <height>60</height>

        <keyFrameInterval>5</keyFrameInterval>

        <modeFps>10</modeFps>

        <qualityBandwidth>0</qualityBandwidth>

        <qualityPicture>90</qualityPicture>

        <enableH264>true</enableH264>

        <h264Level>2.1</h264Level>

        <h264Profile>main</h264Profile>

    </profile>

Save the file and then join a BigBlueButton session and choose the resolution "very low" and you'll see a grainy 80x60 video stream.

Regards,... Fred

On Sun, Jun 17, 2018 at 12:31 PM Pccom Frank <pccom...@gmail.com> wrote:

Can someone help to offer a 80x60 tiny webcam size option for kids and poor men? Instead of increasing the band width,  I am thinking to reduce the traffic. 

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

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[Anton Georgiev]

Hi Frank,

Are you asking about webcams on the Flash client or the HTML5 client?

Best regards,

Anton

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

Visit this group at https://groups.google.com/group/bigbluebutton-dev.
For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@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 bigbluebutton-dev+unsubscribe@googlegroups.com.
To post to this group, send email to bigbluebutton-dev@googlegroups.com.

[Pccom Frank]

html5

You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-dev/r0qmh1zQqAo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bigbluebutton-dev+unsubscribe@googlegroups.com.

[Pccom Frank]

My default is html5. I found no where can choose the low quality of camera settings.

On Mon, Jun 18, 2018 at 8:26 PM, Pccom Frank <pccom...@gmail.com> wrote:

html5

[Chad Pilkey]

There's no webcam quality selection in the HTML5 client yet.

On Tuesday, June 19, 2018 at 6:53:48 PM UTC-4, Pccom Frank wrote:

My default is html5. I found no where can choose the low quality of camera settings.

On Mon, Jun 18, 2018 at 8:26 PM, Pccom Frank <pccom...@gmail.com> wrote:

html5

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.

--

BigBlueButton Developer

http://bigbluebutton.org/

@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 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.

--
You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-dev/r0qmh1zQqAo/unsubscribe.

To unsubscribe from this group and all its topics, send an email to bigbluebutton-...@googlegroups.com.
To post to this group, send email to bigblueb...@googlegroups.com.

[Pccom Frank]

Right. I am trying to reduce the window size to force a smaller webcam size.

[Chad Pilkey]

The window size has no relevance on the bandwidth. If the source stream is bigger than the displayed video it's scaled down on the client side. The bandwidth doesn't change in that case. The only way to reduce the bandwidth is to reduce the quality that is sent from the source or process the video on the server side and lower the quality and re-stream that. The best solution is to change the quality at the source.

[Pccom Frank]

That is why my rendering server have hard time to cope with audio and video syncing.