CU-SeeMe general information, v. 1.0 (94-10-07)

Michael Sattler, San Francisco (
Fri, 7 Oct 1994 23:59:16 -0400

CU-SeeMe discussion mailing list general information (94-10-07).

* Q. What is this message?

This message is automatically posted periodically. As it may contain
information that (1) you'll someday need, and (2) is occaisionally updated,
please retain the latest version of this message. Comments, suggestions,
corrections to Michael Sattler <>.

* Q. How do I unsubscribe from the CU-SeeMe discussion list?

Send an e-mail message to containing a _body_ that
says "unsubscribe CU-SeeMe-L" (less the quote marks).

If your are unable to send this unsubscribe request from the same account
from which you subscribed (the listserver remembers), please send your
unsubscribe request to the CU-SeeMe list manager, Joanne Callahan

To see the other commands this list-server recognizes, send an e-mail
message to containing a _body_ that says "help".

* Q. What if I'm only interested in hearing when a new version is out?

The discussion list is the avenue for all sorts of social discourse that
somehow concerns CU-SeeMe. It may be, well, exhuberantly prolific. If
you're being swamped you may be interested in the CU-SeeMe announcements
list, which posts announcements from the CU-SeeMe development team (like
releases of new versions, problem resolutions, announcements about t-shirt
day :-). All messages sent to CU-SeeMe-Announce-L will be relayed to
CU-SeeMe-L, so there is no reason to be subscribed to both.

To subscribe to CU-SeeMe-Announce-L send an e-mail message to containing a _body_ that says "subscribe

* Q. How do I send mail to the people subscribed to this list?

Send mail to

* Q. How do I send mail to the CU-SeeMe development team?

Send mail to They read the list; the appropriate
developer will reply (when they're not banging on the code :-).

* Q. What reflectors are out there?

There is no "official" world-wide list of reflectors. I do actively
maintain and distribute a list that is posted periodically to this list via
e-mail. The list is also available via the WorldWideWeb at

I'm investigating alternative methods of delivering this information that
prevents the tab characters (which are significant to the
CU-SeeMe/Macintosh parser) from being converted to spaces. Please bear
with me.

* Q. What video cameras work with CU-SeeMe?

Eva and Borre Ludvigsen's house in Norway is all wired for CU-SeeMe. See
it, and information about video cameras (and more) at

Connectix's QuickCam video camera doesn't currently work with CU-SeeMe
(especially as it's not in production yet). The CU-SeeMe team is in
contact with people at Connectix, so there's good reason to hope for the

* Q. Where may I get the latest version of CU-SeeMe from?

* Q. What should I do when I report a problem or request help?

Please send us a detailed description of all the steps you take to
reproduce the problem, even if you think it's not important. Please also
include information of your system and the version of CU-SeeMe you're
using. For example:

Hardware: Mac PowerBook 520c, 12mb RAM
Software: MacOS 7.5, MacTCP 2.0.4, lots of INITs/CDEVs
Target: CU-SeeMe 0.70b12

* Q. How is the video being compressed?

Here's a rough description of the CU-SeeMe compression, extracted from a
previous posting:

The first step in the CU-SeeMe video encoding, is to represent the video
image using 4 bits/pixel (16 shades of gray). The image is then subdivided
into 8x8 pixel squares, which are treated as independent units. When a new
frame of video is acquired, a square is transmitted if it differs
sufficiently from the version of that square that was most recently
transmitted i.e., if it differs from what the recipients are currently
displaying (assuming no packet loss). The index used to determine how
different a square must be in order to trigger updating is roughly the sum
of the absolute values of all 64 pixel differences in an 8x8 square, with a
multiplicative penalty for differences that occur near each other within
the square. The cut-off value can be adjusted by the "Tolerance" control
under "Compression" controls, and should be set as high as possible without
corrupting the picture too much.

Since CU-SeeMe uses an unreliable ("best-effort") transport mechanism
(UDP), squares are sent on a periodic basis even if they haven't changed,
insuring that a lost update won't corrupt the picture indefinitely. How
often this forced update occurs is controlled by the "Refresh Rate"
control, which specifies the number of frames that will be allowed to pass
before a square is updated.
Once the decision to transmit a square has been made, a locally developed
lossless compression algorithm is applied to each individual square. The
algorithm is designed to exploit spatial reduncancy in the vertical
direction i.e., works well if each row in the square is not too different
from the one above it. Based on informal observations, the algorithm
averages around a %60 compression rate (compressed size is about 60% of the

The main objective in designing these algorithms was to be fast enough for
operation on average Macintosh computers. This is achieved by operating on
rows of 8 4-bit pixels as 32-bit words throughout the algorithms, achieving
a degree of parallelism, in effect. Written down in mathematical terms with
respect to individual pixels, the algorithms look rather goofy, but become
appealing when represented in 680x0 assembly language.

As with any compression algorithm, your mileage will vary depending on the
nature of the data to compress. In the case of CU-SeeMe, the most important
factor is the amount of motion in the video.

* Q. What kind of bandwidth is required for fluid motion?

This is a tough question, because the answer depends so much on the content
of the video, and also on a subjective evaluation of what is "fluid
motion." For an average talking head, I would say around 100 kbits/sec. At
the other extreme, there are 75 kbits in an uncompressed 120 x 160 frame,
which would translate to about 45 kbits/frame with the lossless spatial
compression. Then, if you're willing to call 15 frames/sec fluid motion,
and every frame was completely different from the previous frame, you'd
need 675 kbits/sec. But, really, since the software is free, the best
thing to do is try it out on the sorts of video you have in mind.

* Q. Can you connect directly to another PC via modem and SLIP without
* the reflector software?

As long as you have IP service between 2 machines, you should be able to
connect them without a reflector. You cannot involve more than 2 machines
without a reflector, however.

* Q. Is the source code available?

The source code is not currently available, but will be, once we get it
cleaned up and make some decisions about what usage restrictions should be
imposed. The main reason source is not available is that it is not finished
(for any value of "finished"). Though it's not especially relevant to this
question, it's worth mentioning that much of the code was developed without
public funding.

_/ Michael Sattler <> Don't try to teach _/
_/ FTP Software, West Coast Operations a pig to sing; _/
_/ Quality Assurance Manager it's a waste of time _/
_/ and it annoys the pig. _/