CU-SeeMe Video

  Locations of visitors to this page
be notified of website changes? subscribe
CU-SeeMe

 

CU-SeeMe Home

Frequently Asked Questions

User's Guide

Internet TV with CU-SeeMe

Email Lists

Reflector List

Firewalls

Troubleshooting Macintosh

Troubleshooting Macintosh Audio

Troubleshooting Windows

Reflector FAQ

Video FAQ

Macintosh Configurations

Windows Configurations

MBONE

Add My Reflector

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

CU-SeeMe Video

This is about CU-SeeMe video. Check the platform-specific FAQs for hardware and configuration answers.


Question: How does CU-SeeMe compress the video?

Answer: Tim Dorcey said:

Here's a rough description of the CU-SeeMe compression, extracted from a previous posting by Tim Dorcey of the CU-SeeMe development team:

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 original).

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.


Question: What does the little outline box or frame around the video window mean, and why it keeps blinking on and off?

Answer: Tim Dorcey said:

The black border means that CU-SeeMe is using the general Mac toolbox routine, CopyBits, to update the video window, which it does whenever the video must be cropped (i.e., when the window is not fully exposed). Otherwise, CU-SeeMe will draw directly to the screen, which is must faster. The black border is drawn to alert you to the performance penalty, which may or may not be significant depending on how many windows you have open, how often they are being updated, how fast your machine is etc. You can get rid of the border by moving your video window or whatever is obscuring it. In the version 0.80, soon to be released, the borders are not so obtrusive (half the width) and also there is a preferences item which allows you to always use CopyBits, which is necessary for proper operation in some circumstances. In that case, the borders are omitted.


Question: "Empty office" video bothers me. What to do?

Answer: Tim Dorcey said:

Note also that if you don't like what you see, you can close someone's window. This will terminate the stream from the reflector to you and if nobody is watching a particular stream, it will be terminated from the source to the reflector. So, shut down those windows you don't like! On a bad (i.e., SPIP/PPP) connection, this may be easier said than done, as windows tend to pop back open for reasons I outlined in an earlier posting.

However, this problem can be circumvented in 0.70b1 by setting the max windows Preferences item to a small number. Finally, I will plead guilty to often broadcasting an empty office ("Tim@cornell"), but I'm allowed (for debugging purposes).


Question: Generally, what limits my output frames-per-second?

Answer: Tim Dorcey said:

It's mainly the network, or more accurately, the kilobits/sec rate cap setting. I think the default cap is 80 kbpsec, which is sensible unless you know that there is additional *unused* network capacity between the machines. Note also that the cap is automatically adjusted (within the user-settable range) on the basis of packet-loss reports returned by each person receiving your video. Depending upon other activity on your ethernet, you could probably set the cap much higher. At some point, then, the processing speed of your machine will become the limiting factor. E.g., when the cap is set high enough on a Quadra 700 I can transmit about 20 fps with a lot of motion, but it sounds like you have a slower machine.


Question: How can I help to conserve bandwidth?

Answer: Tim Dorcey said:

The recent discussion of CU-SeeMe bandwidth usage raised the issue of what types of video are more or less appropriate for transmission when bandwidth is limited. E.g., is it good network behavior to broadcast the inside of an empty office? The answer, of course, is no, it is not good behavior to broadcast the inside of an empty office when bandwidth is limited, but the answer is irrelevant since CU-SeeMe does not _broadcast_ anything. It only sends video to machines that want it. I.e., a reflector will only forward video to recipients who have that window open, and a video source will stop transmission to the reflector if no one is watching.

The implication of this is that video receivers are just as responsible as video sources for the bandwidth that is consumed (sounds kind of obvious when you say it that way). Hence, to be a responsible bandwidth consumer, it is essential to close windows that you are not interested in. If no one is watching any windows, then choose "Stop Receiving" from the Conference menu. There is really no sin in leaving CU-SeeMe running with a picture of your empty office...the greater sin is to have your monitor full of live video windows when your office is empty. This point needs periodic re-emphasis, I think, because it is so contrary to the way that broadcast television works.


Question: Does the bandwidth limit in the Preferences limit receive as well as transmit?

Answer: Tim Dorcey said:

No, the bandwidth limit applies only to your transmission rate. The only way you can reduce the incoming rate is by closing windows. This is an obvious limitation that we intend to remedy. Eventually, you will be able to set a reception rate cap, and then allocate that bandwidth as you desire to the video resolution/size, frame rate, and number of windows displayed. (That is, to choose whether to watch lots of tiny windows at a slow frame rate or a single large window at a high frame rate).


Question: What kind of bandwidth is required for fluid motion?

Answer: 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.


Question: Somebody claimed 22 fps on a modem connection. Is that possible?

Answer: Tim Dorcey said:

Since CU-SeeMe only transmits the portions of a picture that have changed significantly from the preceding frame, this is entirely possible when the picture is not moving much. Of course, 22 fps is no more impressive than 1 fps when all the frames are the same.


Question: The last adrenalin rush for me will be the images displayed in full living colour; can this be done?

Answer: Tim Dorcey said:

The main obstacle to color video over the internet is the bandwidth requirement. Well, that's not exactly true. It's my figuring that with enough cpu power on your desktop, you could send color without using much additional bandwidth. Conversely, with enough bandwidth, you could send color without much additional cpu power. Clearly, there are existing network/cpu configurations where one or the other of these approaches would be viable. However, one of the central objectives in developing CU-SeeMe was to make it available to the widest possible range of users, under the belief that the value of a communication technology is in large part determined by the number of people with access to it. While you may have a network/cpu that could handle color without difficulty, that doesn't do you any good if you are the only one with such a configuration. That having been said, we do intend to support color at some time in the future. Of course, the extra bandwidth that is required will need to be taken from somewhere else, either by reducing the frame rate, and/or the image size/resolution.


Question: I am receiving the four-part image of the computer laboratory at Iowa as an enlarged image only on the Macintosh computer. The MS-DOS computer does not receive them as enlarged. Occasionally others send their image as an enlarged photo and it really slows the computer and network down. How can I be sure that I do not send an enlarged photo? How are others doing it?

Answer: Tim Dorcey said:

In the Mac version, the size of the transmitted image is set by an item under the "Compression" controls. In particular, you can choose "Standard Resolution" or "High Resolution." The term "resolution," rather than "size" was chosen, because a receiver can choose to display either source size (120x160 or 240x320) at either display size.

In theory, transmitting the larger source size should not require greater bandwidth, since CU-SeeMe will transmit fewer frames/sec to stay under the kbpsec cap. So, the real sin is in setting the cap too high. Actually, for a given cap, there will be some minor differences in network utilization for the differently sized images:

  1. The large image will generate a "burstier" stream since all of the data required to update a single frame is sent at once regardless of how much there is (to be followed with a longer pause to make up for the outburst).

  2. The smaller image will generate a higher packet rate (with smaller packets), since at least 1 packet must be sent to update each frame regardless of how little change there is.

It has been our experience, that for a given kbpsec cap, people generally prefer the smaller image at a higher frame rate, but, of course, this will vary with the nature of the material being transmitted.

previous   next

Questions about CU-SeeMe? help Ask the readers of the CU-SeeMe Mailing Lists.

Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me email. Thanks!
 

What's New?  •  Search this Site  •  Website Map
Travel  •  Burning Man  •  San Francisco
Kilts! Kilts! Kilts!  •  Macintosh  •  Technology  •  CU-SeeMe
This page is copyrighted 1993-2008 by Lila, Isaac, Rose, and Mickey Sattler. All rights reserved.