CU-SeeMe settings for modem usage

Jan Engvald LDC (Jan.Engvald@LDC.lu.se)
Sun, 12 Nov 1995 12:15:15 +0100


>I have a question about optimizing the Mac cuseeme for transmission with
>a 28.8 modem.. What should the standard compression rates be set at..
>The Change tolerance and refresh rate I mean.. Also the min and max
>transmission rates... I've been told 5 and 20 for these
>
>what should they be for the fastest transmission? I am using a Centris
>610/Quickcam Combination, and only sending anywhere from 0.0 FPS to .2
>FPS

For sending audio and video through a 28800 bps connection I recomend
the following settings:

For audio choose 16 kbps delta audio and 100 ms buffer time. No other
setting will give lower line load (but it is still rather high, on the
average 21 kbps + IP header overhead).

Keep refresh rate value at 100 but set change tolerance as high as
possible without getting too many "dirt-spots" at the trailing side
of a moving edge. A lower value causes more of the picture to be
updated for each frame and that means a lower frame rate. In my case
a value of 34 is acceptable and 36 will give too much dirt. The optimum
value is dependent of how much noise the video signal has.

If you are using CU-SeeMe for Mac ver 0.83b3 the set Min Cap to 10,
Max Cap to 26 if your connection actually gets a 28800 speed, else
to 24 if you get 26400 speed. Set Mac Cap w/out audio to the same
value.

For all versions prior to 0.83b3 audio is not included in cap calculations,
set Min Cap to 2 and Max Cap to 6. This is if audio is sent continously,
if you talk in short bursts you can set Max Cap higher.

The above settings assume you prefer low frame rate without packet loss
rather than high frame rate with packet loss. The latter case causes
intermittent audio interrupts and incompletely updated video frames.
But with the 0.83b3 version there is not much of a comprimise, you
get the best of both (high frame rate if no audio, low packet loss
with audio).

If there is too much change in the video picture (panning, scene change),
you will still get a short audio interrupt. This is because of that
the all video packets in a frame are sent in one burst, temporarily
blocking audio packets. I have just sent a request for change to Cornell
about this, asking for some audio packets (they are small) to be sent
in between video packets (they are big).


Jan Engvald, Lund University Computing Center
________________________________________________________________________
Address: Box 783 E-mail: Jan.Engvald@ldc.lu.se
S-220 07 LUND Earn/Bitnet: XJELDC@SELUND
SWEDEN VAXPSI: psi%2403732202020::xjeldc
Office: Soelvegatan 18 X.400: S=Engvald/G=Jan/O=ldc/
Telephone: +46 46 2227458 PRMD=lu/ADMD=sunet/C=se
Telefax: +46 46 138225 WWW: http://www.lu.se/