Automated: CU-SeeMe pseudo-FAQ v. 1.1

Michael Sattler, San Francisco (
Mon, 17 Oct 1994 14:21:54 -0400

* Version 1.1, dated 94-10-09.

* Q. What is this?

This document is a general overview of the CU-SeeMe discussion list, also
known as CU-SeeMe-L. It is an unoffical document, as I have no connection
with the CU-SeeMe project. Please retain the latest copy you've recieved,
as it may contain information that you'll someday need.

This document is automatically sent periodically to the CU-SeeMe-L mailing
list and is available as

Please send additions, corrections, deletions, and comments 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. 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

Users of the CU-SeeMe for Windows should include information about their
stack and version of Winsock.

By the way, the CU-SeeMe development team reads the mailing list.

* Q. Who are the members of the CU-SeeMe development team?

(From a member of the team) here's the scoop on the current CU-SeeMe
development team:

Dick Cogger ( Project manager; also, it was his idea in
the first place (though he got the basic idea to do videoconferencing on
the Internet from what folks were doing in the UNIX world).

John Lynn ( Programmer responsible for reflector program
and audio component of Mac application.

Larry Chace ( Programmed text stuff in current Mac
application. Has been working on an "auxillary data transport"
mechanism that will allow reliable transmission of other sort of data
besides video and audio. A version using this to transmit still images
will soon be released.

Aaron Giles ( Works for Cornell Med School;
developing version of CU-SeeMe oriented toward medical applications (e.g.,
remote consultation). Did initial port to PowerPC, Preferences file,
miscellaneous interface items. To support his medical application, he
built a plug-in interface within CU-SeeMe, so that people can write stand
alone code modules that add functionality to CU-SeeMe at run-time. This
version will soon be released along with documentation for the plug-in
interface. He's the only real Mac programmer on the project and also wrote
the program "JPEGView".

Aaron Freimark ( Now at Cornell Med School, and
not active in the project. Wrote nickname and button handling code while a
student at Cornell.

Rich Kennerly ( Working on Windows version.

Steve Edgar ( Did initial port to Windows, but not
currently active on project.

Tim Dorcey ( Wrote original Macintosh version. Responsible
for video processing.

* Q. What's with the strange email addresses for the team?

When we adopted the network id (e.g., td11 or jal7) system several years
ago, we were assured that it didn't matter if they were hard to remember
because the actual id would remain behind the scenes. This is true in the
sense that you can reach anyone at Cornell using the address: where "first" need only contain enough characters of
one's first name to resolve uniquely.

Actually, the system is even more flexible, as it doesn't matter in what
order the first and last name are given, except that whichever is listed
second must be given completely. Also one can use other delimiters (e.g.,
".","-") besides the underline.

Tim Dorcey, for example, can be reached as: Tim_Dorcey or T.Dorcey or
Dorce.Timothy but not Dorcey_Tim. This bizarre parsing has unexpected
effects: like you can't use John_Lynn because it gets confused with
Lynn_Johnson! So, in the end, lots of people are having to use the actual
netid to get uniquely identified.

* 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.

* 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.

_/ 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. _/