For an alternative view, the way the software operates should be
considered. I think I've read in the cuseeme info that the program
"evaluates" (for lack of a better term) the frame that that has been
captured against previous frames that have been sent. It then sends frame
info (maybe not necessarily a whole frame) that can best represent the
change from the previous frame. This is so that the movement in the frame
can be simulated with lower bandwidth (have you noticed that the cuceeme
frames are "different" from typical streaming video frames?). I noticed that
with using a snappy preview screen and cudoodle I got very high frame rates.
The preview frame was updated only about once every 2 seconds (snappy,
cudoodle, tcp/ip, enhansed cuseeme, and some other stuff running all at once
slows snappy down on a 486!). I remember seeing my video having something
like 15 fps on a 28.8 connection. I think cuseeme was "evaluating" the frame
and sending the needed changes at 15 fps. It could do this because there was
no (or very little) actual "frame change" info that needed to be sent each
time.
OK, experiment time! Get a copy of cudoodle and fire it up along with the
quick cam when doing cuseeme. For a picture, you can do a screen capture of
your own video frame and use it as a control pix (or maybe any small b/w pix
will do). Put the photo under the cudoodle capture area and let it sit for a
few seconds. Check to see what the fps stablize at in your video frame. Then
use your mouse to slowly move the pix around under the capture area and see
how the frame rate changes. If there is a change, it may be due to the
amount of "different" frame info that has to be sent. Not rocket science,
but easy to try.