Re: problems with color and audio

John Ingham (johningh@tafe.sa.edu.au)
Fri, 28 Feb 1997 13:13:42 +0930


Dr. Bob asked several "supplimentary" questions. The first I'll
para-phrase as "Is receiving or transmitting CU-SeeMe more processor
intensive?"

Transmitting is more processor intensive - my little Macintosh LC-1
(Motorola 68020 processor is equivalent to an Intel 80286 - from almost the
dark ages of micro-computing) does quite a good job receiving CU-SeeMe
video and audio, but "hangs" if I try to speak. Of course a processor is
doing two different tasks when simultaneously transmitting and receiving
live video but typically video codec/decoders are "asymetric" requiring far
more "grunt" to compress than de-compress. So increasing the speed/power
of your processor will show first as an improvement in your transmit frame
rate and the in the ability to utilise more advanced audio compression
algorithm (such as Digitalk and Voxware).

>Do the options we choose have to match?

No. The receive part of your CU-SeeMe will track (within its capabilities)
and incoming audio algorithm regardless of the transmit algorithm you have
selected.

>Does pausing your video with the icon under your picture do the same thing
>as selecting the Stop Sending Video menu item?

No. If you select the Stop Sending Video menu item your video window on
the receiver's screen will close, where as clicking on the little red "Stop
Sign" icon under your own video window will merely stop transmitting video
packets - ie cause your picture on the receiver's screen to freeze.

>If the problem is my receiving her audio, do we both need to freeze our
>videos? Her to free up bandwidth to send, me to free up bandwidth to
>receive? She did try SSV herself, but I left mine going...

Transmission via a modem or other serial connection is "full duplex" - that
means that data being transmitted does not impinge upon data being received
and vice-versa. You only need to freeze YOUR video window when YOU are
speaking, SHE only needs to freeze HER video window when SHE is speaking.
When either of you are just passively listening you don't need to freeze
your transmit video. (Sorry, what's "SSV" - I have a mental block?)

>This caps business I have to say is the most difficult part of using CUSM.
>How does one go about deciding what the LCD is? This should all be in a FAQ
>somewhere, and I think I've even seen it, but I couldn't find it today, not
>in the material from Cornell, anyway.

The "caps business" is really not too hard to understand. Everyone has a
limitation to their transmit bps capability which may be different from
their receive bps capability. For instance, these new 56 kbs modems are
asymmetrical; while they can download data at 56 kbs they can only upload
data at 28.8 kbs. So if you (using an ISDN or LAN connection) were
contacting someone on one of these new modems you'd expect a different fps
rate for receive than for transmit.

The point however is that each person should select their own Tx and Rx cap
to suit their own circumstances. For example I might have a 28.8 kbs modem
so I'd typically set both my caps to 28 kbs. However, I'd be wise to bear
in mind that I don't always achieve a 28.8 kbs connection with my ISP - on
occasions it might be as low as 19.2 kbs so I'd need to take this into
account and routinely set my caps to (say) 20 kbs.

If I was to directly connect with you (who set your caps to say 50 kbs) you
would receive a maximum of 20 kbs from me (because that it what my tx cap
is), and because our two programs exchange data on each other's
capabilities, your system would throttle down your Tx rate to 20 kbs to
suite my receive cap. It gets more complicated than that if we are
communicating via a reflector though, and I'm not sure of the rules there.
But it has been my experience that I get many more broken up pictures via
reflectors than direct connections. It is my impression that reflectors
throttle back the rate of data sent to slower sites but this still means
that when a fast site is transmitting there is packet loss end-to-end
resulting in broken pictures.

You see, one of the compression techniques is to send only picture UPDATES.
But this assumes that the starting picture stored in the computer of the
transmitter is the same as that of the receiver. If there has been any
data loss then this is not the case and so the picture gets progressively
"shattered". That is why "refresher" blocks are sent randomly (as a
background task) even though there has been no change in that part of the
picture.

It also explains in part why when connecting directly point to point you
get a clean picture quite quickly, while when connecting via a reflector it
takes some time to get a clean picture. When point to point the
transmitter sends an entire frame first up. Whereas when you connect to a
reflector you don't have the benefit of a starting frame - you just have to
wait for a complete set of "refresher" blacks to be sent by the
transmitter, and this depends on the preferences set in the transmitting
computer. (Ever notice that when connecting to one of the NASA reflectors
during a de-briefing how quickly you get a complete picture? This is
because NASA is switching between multiple cameras and so the picture gets
totally renewed much more regularly.)

John Ingham
Supervisor, Technical Operations, TLC (Tele-Learning Consortium)
Adelaide Institute of TAFE (Training and Further Education)
GPO Box 1872 Adelaide South Australia 5001
Ph: +61 8 8207 8550 Fax: +61 8 8207 8552
Email: johningh@tafe.sa.edu.au
Web Site: http://www.tafe.sa.edu.au/video-conf/
=======================================================