Gstreamer solves nearly all of this for you, with very little effort, and also integrates nicely with the Glib event system. GStreamer includes V4L source plugins, gtk+ output widgets, various filters to resize / encode / decode the video, and best of all, network sink and sources to move the data between machines.

For prototype, you can use the gst-launch tool to assemble video pipelines and test them, then it s fairly simply to create pipelines programatically in your code. Search for GStreamer network streaming to see examples of people doing this with webcams and the like.

I m not sure about the actual technologies used, but this can end up being a huge synchronization ***** if you want to avoid dropped frames. I was streaming a video to a file and network at the same time. What I eventually ended up doing was using a big circular buffer with three pointers: one write and two read. There were three control threads (and some additional encoding threads): one writing to the buffer which would pause if it reached a point in the buffer not read by both of the others, and two reader threads that would read from the buffer and write to the file/network (and pause if they got ahead of the producer). Since everything was written and read as frames, sync overhead could be kept to a minimum.

My producer was a transcoder (from another file source), but in your case, you may want the camera to produce whole frames in whatever format it normally does and only do the transcoding (with something like ffmpeg) for the server, while the robot processes the image.

Your problem is a bit more complex, though, since the robot needs real-time feedback so can t pause and wait for the streaming server to catch up. So you might want to get frames to the control system as fast as possible and buffer some up in a circular buffer separately for streaming to the "control panel". Certain codecs handle dropped frames better than others, so if the network gets behind you can start overwriting frames at the end of the buffer (taking care they re not being read).

When you say a new video port and then start talking about vlc/gstreaming i m finding it hard to work out what you want. Obviously these software packages will assist in streaming and compressing via a number of protocols but clearly you ll need a network port not a video port to send the stream.

If what you really mean is sending display output via wireless video/tv feed that s another matter, however you ll need advice from hardware experts rather than software experts on that.

Moving on. I ve done plenty of streaming over MMS/UDP protocols and vlc handles it very well (as server and client). However it s designed for desktops and may not be as lightweight as you want. Something like gstreamer, mencoder or ffmpeg on the over hand is going to be better I think. What kind of CPU does the robot have? You ll need a bit of grunt if you re planning real-time compression.

On the client side I think you ll find a number of widgets to handle video in GTK. I would look into that before worrying about interface details.