Re: Newbie Help - and the Holy Grail of CuSeeMe

Scott Lacroix (
Fri, 03 Apr 1998 09:37:02 -0400

At 12:46 AM 4/3/98 -0600, Jason Williams wrote:
>On Thu, 2 Apr 1998, Brian K. Dowtin wrote:
>> Settings are kind of important in getting video
>> Seems that for a while these were unpublished or at least
>> any reasoning behind the settings was unpublished.
>Historically (when I got into CU in 1994), settings weren't published
>because they really weren't that important. A default max send of 80kbps
>and max receive of 500kbps worked great when I was on a T1 :)

<nasty, biting sarcasm on>
Uhm, things worked great for you on a T1 and thus, no-one else published
the meanings of the setting? Did they all check with you or what?
<nasty, biting sarcasm off>

>> Min Send: 1 Max Send: 15
>> Men Recv: 1 Max Recv: 28
>The Mins don't really do much for bandwidth at all...The only real reason
>to set your mins that low is so no reflectors can complain and force you
>out of the reflector for incorrect mins. (I try to convince reflector
>operators that forcing people's mins to 1 doesn't save any bandwidth for
>the reflector and only ticks the participants off).

Not entirely true. If you want a high quality connection and you push your
Min Send up then it will definately affect bandwidth.

Min Send: 15 Max Send: 28

Will help guarantee that you send decent vid, but it's going to cause your
outgoing bandwidth to be over 15kbs constantly. Min Recv, on the other
hand, doesn't do alot for ya, or your bandwidth...

>> The other thing is video's open. I can guarantee
>> if you open all 8 videos, you wont see 8 folks moving
>> if you're on a modem.
>Oddly enough, this depends a lot on the reflector you are at. I've opened
>up to 6-7 vids on my public reflector (MPCS server) and received them just
>fine. A little slow, but they all updated.

Well thanks! We worked really hard on that bandwidth manager... :)
But what you're doing is taxing it pretty heavily. If you're on a modem
connection with 6-7 windows open, you're potentially recieving 15-20 kbs
from each user, so a total of 90-140 kbs of data... Your modem won't do
more than 56 kbs... The server REALLY tries to be intelligent about what
kind of data it drops (since it can't POSSIBLY send it all) but if you
watch you'll see flush rates of 50% - 70% or more... Depending on the
codecs that the other clients are using, this may seriously affect the vid
IE: Greyscale & MJPG (which happen to be the most popular) should still
give the best quality. H.263 & WhitePine Color users will look particularly
bad as flush rates climb...

>> I've found opening 2 videos seem to show fairly decent
>> on each. More than that, folks just seem to stand still
>This has something to do with color I believe...Color needs the bandwidth
>and doesn't like high packet loss (MJPEG at least). If you open a lot of
>vids, the packet loss creeps up and it stops updating. Again, on a MPCS
>server this doesn't seem to be the case. I've also had good success with
>color vids on Enhanced Reflectors.

Yes, color is generally worse the grey for bandwidth requirements... HIGH
QUALITY color is obviously the worst. WP CU-SeeMe ships with a quality
default of 75% for MJPG color (which is great for Lan connections). If the
remote modem users switch thier quality down to 25% or so, the client will
send smaller frames and the server can be more intelligent about which data
it can drop... Thus you get a better exerience with multiple videos.
I expect that most of the people on Jason's server are using optimal (or
close to optimal) settings since he (and many others there) are well versed
in the CU protocol & how to tune thier clients.

>> Again, I'm sure the guys here who've written the code
>> can give you an explanation and specifics.
>I haven't written the code really..but there's my $.02 :)

I have... *G*
- Scott


,-==================================-.-==================================-. | I haven't lost my mind, it's backed | Scott LaCroix ( | | up on tape around here somewhere... | Sr. Software Engineer ___ | | - Author Unknown | White Pine Software ./_ -\. | | #include<disclaimer/std.h> | q| o O |p | `-==================================-^-=====================oOOo=~U~=oOOo-'