Re: frame rates <=> data rates & values > 100

Fri, 13 Oct 1995 09:43:50 +0100

>>>We are setting up cu-seeme on a wan and are getting very slow frame rates
>>>although are transmission rates are very high 80-150 kbits/sec. We are using
>>>the reflector program on an hp 9000. What are we doing wrong? frame rates
>>>are generally 0 -1 with 8-bit encapsulated mode. Thanks for help.
>For a fixed transmission rate, unusually low video frame rates could be
>explained by:
>1) mis-configured compression parameters
>2) lots of "motion" in the video
>3) competition with other data such as audio, text, or slides
>The first is the most likely. For maximum frame rates, use "Standard
>Resolution," set the "Change Tolerance" as high as possible without
>observing corruption in the video, and set the "Refresh Interval" to at
>least 100. Using "High Resolution" has no effect on video quality unless
>recipients are viewing the large size 240 x 320) image, and it cuts the
>frame rate dramatically. The correct value for "Change Tolerance" depends
>upon the camera, digitzer and lighting conditions. You do not need to be
>transmitting video to observe it's effect, but you do need to move around.
>Increase the value of Change Tolerance until you start seeing parts of the
>picture "tear off" as you move. Then, back it down until generation of
>these artifacts is reduced to an acceptable level.
>Frame rates will also be reduced the more each frame is different from the
>preceding. This will occur naturally if there is a lot of movement in the
>scene, but can sometimes be a spurious result of lighting effects. To
>assess this possibility, connect to self, and then change the size (zoom
>box) of the second "received" video image. A change in window size will
>cause the video to go gray, and then to fill in, only as the changing parts
>of the image are updated. Parts of the image that are supposedly static
>should only fill in gradually, as the "Refresh Interval" (how many frames
>are allowed to elapse before an unchanged portion of the picture is forced
>to update) expires (for the purpose of this test, you might want to
>increase Refresh Interval to a large value). If background is being
>unnecessarily updated, you try increasing the "Change Tolerance," or try
>changing the lighting or background (e.g., flourescent light cycles can
>cause spurious "motion"). As an interesting example of the kind of
>unexpected phenomenon that can occur, someone alerted me to the fact that
>my data rate would rise dramatically at night, when my office was
>completely dark. Apparently, the digitizer or camera was increasing its
>sensitivity to the point that it was detecting random noise in the image
>(that was introduced by some other part of the system).
>3) is an unlikely possibility, as these data streams generally don't demand
>a lot of bandwidth compared to video. On the other hand, audio set to the
>64 kbps encoding, and being transmitted continuously, would take a pretty
>big chunk out of 80-150 kbps.
>The above comments are Mac-centric. The basic concepts should be identical
>for Windows, though I'm not certain that all of the user interface items
>are in place at this time.
>Tim Dorcey
>Sr. Programmer/Analyst (607) 255-5715
>Advanced Technologies & Planning
>CIT Network Resources
>Cornell University
>Ithaca, NY 14850

Great info this to setup Cuseeme !

But, I'm able to set Change Tolerance and Refresh Interval values greater
than 100 (I'm using mac version 0.83b2).

What does it means ?

-Moreno Borsalino


CSELT (Centro Studi E Laboratori di Telecomunicazione) S.p.A.
V. Reiss Romoli, 274 10148 Torino (ITALY)

Ph. : +39 11 2286823
Fax : +39 11 2286862
E_Mail: moreno.borsalino@CSELT.STET.IT
Home Page :

/ / ___/ ___/ / /_ _/
/ /--/___ / ___/ /_/ / / /