Video Quality is Not Good..

[Mehul Shah]

Hi gurus. I have install bbb on CentOS and its working fine. I have
many question regarding Video Conferencing.

1. What bandwidth require (at server & client side ) for 1-1 video
chatting.
2. What bandwidth require (at server & client side ) for 1-10 video
multicasting. One person is multicast his video to 10 people.
3. Is the video traffic going from server or it`s peer 2 peer. ?
4. How many user with video chatting it can handle.
5. Is frame per seconds configurable
6. Which codecs are used for video conferencing..
7. It is scalable upto how many users ?
8. Can i use asterisk for video conferencing. ?

I am also facing problem of bad video quality. I can use video feature
but quality is
very bad. The person to whom i m seeing is pixellised. Though i am
having 1mbps of upload and download speed. What are the tips require
to improve the video quality for video conferencing.

Thanks...

[Fred Dixon]

Hi Mehul,

Cool that you got it installed on CentOS!

Here are the answers to most of your questions.

On Dec 8, 1:34 pm, Mehul Shah <shahmehul...@gmail.com> wrote:
> Hi gurus. I have install bbb on CentOS and its working fine. I have
> many question regarding Video Conferencing.
>
> 1. What bandwidth require (at server & client side ) for 1-1 video
> chatting.

For rough approximation, you can use the rule of thumb for 50 KB/s for
upload/download. So if you have two people sharing their web-cam on a
1-1 video, each has one upload and one download stream. That 4 * 50
KB/s = 200 KB/s bandwidth on the server. That's Kilobytes / second.
Note that there is compression at play, so the bandwidth will vary
constantly with the activity being broadcasted.

For example, if I broadcast with my webcam (320x200), then close the
privacy tab on my webcam so it's broadcasting solid black, the
bandwidth for a 50 KB/s stream drops to about 10KB/s.

> 2. What bandwidth require (at server & client side ) for 1-10 video
> multicasting. One person is multicast his video to 10 people.

The math would roughly work out to 1 50 KB/s stream for presenter, and
10 x 50 KB/s stream for viewers, for a total of 550 KB/s.

> 3. Is the video traffic going from server or it`s peer 2 peer. ?

The traffic all goes through the BigBlueButton server (no peer-to-
peer).

> 4. How many user with video chatting it can handle.

There is no hard-coded limit. You'll hit a bandwidth limit before you
hit a software limit. To test, try opening two clients and one
broadcast and one receive. On the receiving client, you can double-
click on the presenters web cam icon to repeatedly open new windows.
Using this method, it's possible to generate lots of subscriber
instances.

> 5. Is frame per seconds configurable

Flash has you set the quality of the video broadcast, which in turn
affects frames per second. These parameters are set in


http://code.google.com/p/bigbluebutton/source/browse/trunk/bigbluebutton-client/src/org/bigbluebutton/modules/videoconf/views/PublishWindow.mxml

in method startPublishing(). For more information on these
parameters, see

http://livedocs.adobe.com/flex/3/langref/flash/media/Camera.html

> 6. Which codecs are used for video conferencing.

Flash is using H.263 Sorenson Sparc codec.

http://en.wikipedia.org/wiki/Sorenson_codec

> 7. It is scalable upto how many users ?

There is no hard-coded limit. You can go as high as your bandwidth
allows.

Obviously, if you have infinite bandwidth, there are software limits,
but you'll likely hit the ceiling on bandwidth before you hit a server
limit.

> 8. Can i use asterisk for video conferencing. ?

BigBlueButton uses red5 for handling the video streams. You could
possibly use Asterisk, but we haven't tried. Basically, red5 is a
open source flash media server and does a very good job a streaming
flash-based media.

>
> I am also facing problem of bad video quality. I can use video feature
> but quality is
> very bad. The person to whom i m seeing is pixellised.

Yes, that's the H.263 codec at work. BigBlueButton is using what
Flash is providing out-of-the-box.

We've not explored yet using other codecs or other open source
solutions (running outside the browser) to capture video, but its open
source, so all things are possible (just depends on how hard you
push).

Can you tell us more about your use case. If this is really
important, you might spur enough interest to improve this area of
BigBlueButton.

Regards,... Fred

[Mehul Shah]

Thanks a lot for your reply and giving appropriate reasons. Kindly see
the reply below..

On Dec 9, 3:15 am, Fred Dixon <ffdi...@gmail.com> wrote:
> Hi Mehul,
>
> Cool that you got it installed on CentOS!
>
> Here are the answers to most of your questions.
>
> On Dec 8, 1:34 pm, Mehul Shah <shahmehul...@gmail.com> wrote:
>
> > Hi gurus. I have install bbb on CentOS and its working fine. I have
> > many question regarding Video Conferencing.
>
> > 1. What bandwidth require (at server & client side ) for 1-1 video
> > chatting.
>
> For rough approximation, you can use the rule of thumb for 50 KB/s for
> upload/download.  So if you have two people sharing their web-cam on a
> 1-1 video, each has one upload and one download stream.  That 4 * 50
> KB/s = 200 KB/s bandwidth on the server.  That's Kilobytes / second.
> Note that there is compression at play, so the bandwidth will vary
> constantly with the activity being broadcasted.
>
> For example, if I broadcast with my webcam (320x200), then close the
> privacy tab on my webcam so it's broadcasting solid black, the
> bandwidth for a 50 KB/s stream drops to about 10KB/s.
>
> > 2. What bandwidth require (at server & client side ) for 1-10 video
> > multicasting. One person is multicast his video to 10 people.
>
> The math would roughly work out to 1 50 KB/s stream for presenter, and
> 10 x 50 KB/s stream for viewers, for a total of 550 KB/s.
>

So if there is 1 presentor and 10 viewer than at the presentor side it
requires 50KB/s of upload stream and at each viewer side they require
50KB/s of download stream. right ? Or at presentor side it requires
50X10 KB/s of upload ? My viewer are all from different location.

> > 3. Is the video traffic going from server or it`s peer 2 peer. ?
>
> The traffic all goes through the BigBlueButton server (no peer-to-
> peer).

Can we do this peer2peer ? OR can we put some multicast group in
between where they will manage bandwidth and broadcast to viewers. So
that i dont have to manage too much bandwidth @ server side. This is
to manage millions of users when using this system.

>
> > 4. How many user with video chatting it can handle.
>
> There is no hard-coded limit.  You'll hit a bandwidth limit before you
> hit a software limit.  To test, try opening two clients and one
> broadcast and one receive.  On the receiving client, you can double-
> click on the presenters web cam icon to repeatedly open new windows.
> Using this method, it's possible to generate lots of subscriber
> instances.
>
> > 5. Is frame per seconds configurable
>
> Flash has you set the quality of the video broadcast, which in turn
> affects frames per second.     These parameters are set in
>

> http://code.google.com/p/bigbluebutton/source/browse/trunk/bigbluebut...

>
> in method startPublishing().  For more information on these
> parameters, see
>
>    http://livedocs.adobe.com/flex/3/langref/flash/media/Camera.html
>
> > 6. Which codecs are used for video conferencing.
>
> Flash is using H.263 Sorenson Sparc codec.
>
>    http://en.wikipedia.org/wiki/Sorenson_codec

Can we use H.264 ? because its much better than h263

>
> > 7. It is scalable upto how many users ?
>
> There is no hard-coded limit.  You can go as high as your bandwidth
> allows.
>
> Obviously, if you have infinite bandwidth, there are software limits,
> but you'll likely hit the ceiling on bandwidth before you hit a server
> limit.
>

Agree

> > 8. Can i use asterisk for video conferencing. ?
>
> BigBlueButton uses red5 for handling the video streams.  You could
> possibly use Asterisk, but we haven't tried.  Basically, red5 is a
> open source flash media server and does a very good job a streaming
> flash-based media.
>
>

The way in which you are doing audio conferencing with asterisk we can
do the same for Video Conferencing. I am stressing more for asterisk
is because i am working with asterisk from last 5 years and have
indepth knowledge of asterisk.

[DJP]

Hi,

No, it's not supported by the Flash client for webcam publishing :-
( One way to do this would be to use xuggler to transcode from h263
from publisher to h264 for all clients...
I hope in a near future Flash will support additionnal codec for
webcam publishing but i doubt so.... They have another "commercial"
product for that : Adobe Flash Media Encoder... Which support H264,
On6, ...

DJP

[Fred Dixon]

Hi Mehul,

> Can we do this peer2peer ? OR can we put some multicast group in
> between where they will manage bandwidth and broadcast to viewers. So
> that i dont have to manage too much bandwidth @ server side. This is
> to manage millions of users when using this system.

Adobe has a peer-to-peer capability in Flash 10, called RTFMP, but
it's proprietary. See

http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol

> The way in which you are doing audio conferencing with asterisk we can
> do the same for Video Conferencing. I am stressing more for asterisk
> is because i am working with asterisk from last 5 years and have
> indepth knowledge of asterisk.

We've been using Asterisk for the voice conferencing and red5 for the
web conferencing (including video). I think what you are asking is
for a flash-to-sip video capability in the client so you could use
Asterisk as the router for video calls. For the existing voice we use
the red5phone project.

http://code.google.com/p/red5phone/

Not sure if this would support video, but might be possible with a bit
of work.

Regards,... Fred

[Walter Tak]

> > > 2. What bandwidth require (at server & client side ) for 1-10 video
> > > multicasting. One person is multicast his video to 10 people.
>
> > The math would roughly work out to 1 50 KB/s stream for presenter, and
> > 10 x 50 KB/s stream for viewers, for a total of 550 KB/s.
>
> So if there is 1 presentor and 10 viewer than at the presentor side it
> requires 50KB/s of upload stream and at each viewer side they require
> 50KB/s of download stream. right ? Or at presentor side it requires
> 50X10 KB/s of upload ? My viewer are all from different location.
>

The presentor only needs to "upload" one feed of 50 Kb/sec and the server
will multiply the packets to the connected users. You could even send to 100
users but only need 50 Kbytes yourself.

If you have a meeting with 5 people then you will receive 4 streams and send
1. Your connection will see 4 x 50=200 kbytes/s incoming data and 1 x 50 =
50 kbytes/s of outgoing data.

Example 1: In 1 giant room with 100 users broadcasting with 100 webcams (1
person 1 webcam) you "only" need 100 x 50 = 5000 kbytes/sec (50 mbit)
downstream and 50 kbytes/sec ( 0.5 mbit) upstream, per user.

The problem there is that the server needs to transmit/broadcast 100 streams
to 100 users = 10.000 streams of 50 kbyte/s each.. Thus 10.000 x 50 kbyte/s
= 5 Gbit/sec

Example 2: You want to host 70 independent meetings with each 5 persons with
1 webcam each @ 50 kbytes/sec (= 200 kbytes/sec downstream per person x 5
persons = 1000 kbyte/sec outgoing data from the server for one meeting)
results in a total server-usage of 70 x 1000 kbytes/s = 70 x 1 mbytes/s = 70
mbytes/s = 700 mbit/s (rougly)

Needless to say that near 700 Mbit traffic all day long will result in a
nice traffic-bill, on the other hand you'd have 350 users using your
videoconference service which should result in decent income as well ;)

Conclusion ; videoconferencing eats traffic. In practise you shouldn't try
to host 200+ users on one server and often not every user transmit the full
50 kbytes/sec and some even join in for viewing and not broadcasting their
own webcam. Or others don't turn on the streams and in that case no data is
transmitted from server to the clients.

If you do sell your service to your manager then make a correct calculation
because wrong assumptions can make you go bankrupt on the traffic-bill :)

W.