Why vidcall is not widely used.

Fri, 6 Oct 95 11:02:45 CDT

I have used Vidcall and find its colors awsome but its speed is slow.
It uses a ramdrive to receive a file and then uncompresses the file to display i
t. Rather than use a buffer for for the xfer it uses an external drive that it m
ust read a byte at a time or so and work with. This is slower than receiving a s
tream to buffer and uncompressing on the fly block by video block.
cuseeme updates blocks on the screen not a whole frame at a time.
Vidcall has no audio.
My biggest gripe with vcall is its ungodly habit of opening and closing windows
at inconvenient times. If my chat/dialog window is open it will close it at
hangup. If I open a connection and then open the chat window the info window
and the phone book window and the connect confirmation window and assorted
other windows pop up on top of what
im doing and i have to close them all to get back to chat. The response time between click and close of windows and other commands
on my dx266 is about 3 to 10 seconds per command as its busy uncrunching a frame.
I have waited 30 secs to get my to a chat window by which time the other party has hung up.
All in all it is a pretty program but slow and bothersome some times. I hope to see cu incorporate color but it would require aout 3 times the data flow.
3 times 4 bits for 16 levels of 3 colors. Wouldnt be too bad only 28 k per frame plus
any overhead for id of each 8 by eight block. On t1 it wouldnt be too bad but
on 28.8 you would get a frame every 10 secs. Not too good but given a 10% only
change in the screen you might get 1 fps color at 160x120 at 28.8 .
We'll see what develops. I still want to see a tsr in dos for popup video
chats. It would run a lot faster.