I did a bit of research around video streaming on the pi and there seem to be several methods used including using VLC or netcat or various other methods but they all seemed to be a little bit high latency and as we are going to be doing live video to a screen we want to keep that down so I went with Gstreamer.
The first page I came across seemed to be ideal : http://pi.gbaman.info/?p=150 and this got me up and going but I ran into issues with the sending and listening commands. http://blog.tkjelectronics.dk/2013/06/how-to-stream-video-and-audio-from-a-raspberry-pi-with-no-latency/ helped with sending but as the commands on both pages were for listening using a Mac I was out of luck. After a quick poke around mailing lists and google fu I have now got it up and running.
So after setting up the environment as described in either of the above I have been using the following commands. I am not a gstreamer scientist and there are probably much better ways of doing it but this seems to be working here.
Sending Pi (pivate-eye) note you will have to change the IP address
raspivid -t 999999 -w 1080 -h 720 -fps 25 -hf -b 2000000 -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay config-interval=1 pt=96 ! gdppay ! tcpserversink host=10.42.0.112 port=5000
10.42.0.112 is the address of the sending pi.
On the listening pi (pi-tv) watch out for the ip address in it
gst-launch-1.0 -v tcpclientsrc host=10.42.0.112 port=5000 ! gdpdepay ! rtph264depay ! h264parse ! omxh264dec ! videoconvert ! autovideosink sync=false
I have done some quick tests as to the latency of the video link and how it changes with resolution. These are only very quick tests so may not be that accurate. The methodology was to put a stopwatch on screen, stream the screen via the webcam with both the onscreen clock and the video playback of the clock visible then to take a picture using a digital camera and then just subtract the differences between the clocks.
320 x 240 = 176 ms
640 x 480 = 137 ms
800 x 600 = 325 ms
As you can see this doesn’t quite look right but it was just a quick test just to get some ballpark figures. I have also not run multiple tests over time to see if there is drift in the lag so there is a lot more work required here. Oh and also there is a good chance that my gstreamer commands could be optimised and improved.
Also can I just say a big thanks to Odie_ on #raspberrypi on Freenode who correctly spotted I hadn’t checked my camera when I couldn’t get it working and suggested the latency methodology and generally kept prodding me until I got it working and documented on the net