Some background to this will help explain why it’s quite tricky under windows.
When you are viewing the webcam, it’s quite likely that you are seeing an overlay graphic. In this instance, the webcam window is actually showing a single colour and the video card is doing chromakey overlay, replacing the “token” colour with the video image. When you view this through VNC, the display becomes a tiled bitmap with no hardware overlay, so VNC is having to grab each part of the screen as a tile, compress and push over the LAN.
I remember having great fun with a Silicon Graphics Indy which had an IndyCam. This was an early forerunner of the webcam but had a really cool feature - there was a local software daemon on the Indy which would squirt the IndyCam stream over the wire and turn it back into a hardware overlay on the viewing machine.
The nearest parallel to this is, I believe, remote desktop displays using X Windows. To accomplish your objective, I would consider running X on your robot brain and using the display redirection built-in to X Windows to present your display on the remote host. I believe (but haven’t done this for along while) that this will work “out of the box”. Fire up the X Windows server on the robot, connect your X client from the remote and it should “just work”.
This will be faster than using VNC as the X display model would allow the webcam data to be sent as-is (and then possibly compressed by the network layer) and then rendered to the display - instead of Windows which would render to the screen, grab the screen into tiles, compress each tile, push across the wire, expand the tile and render!
If you need to stay Windows based, then you may be able to use Windows Media Encoder (aka Windows Media Services). This is an add-in pack for Windows Server (at least 2003, maybe 2000 and possibly is available for Windows 2000 Professional). It will work from a stream source on the local machine, encode for network transmission and allow you to pick it up over the LAN by a normal media player. The first problem here is latency - I tried to do what you describe and found about 2 second latency, ignoring the network stage. Newer hardware might drop this to a tolerable level.
The basic reason this is hard under Windows is that MS haven’t really got retargettable display working in the windows core. X Windows works on a client-server model and allows you to retarget the display with ease.
So, in summary. If you want to stick with Windows, google “Windows Media Encoder”. If you can tweak the platform, google “X Windows Remote Display”.
Hope this helps more than it confuses.
Tim
ps In case anybody feels like nit-picking, I know that X Windows actually has the client/server parts backwards 