As I wanted the full rate video from the camera, none of the above were satisfactory of course. Massive numbers of errors were generated by vlc, amazing to get a picture at all!
I read jamesh's post in the Foundation camera thread about good low latency, so that was the impetus to experiment. I've used netcat successfully for Pi to Pi video streaming, but also wanted to broadcast the pi camera video to potentially several other monitors (via Pi's) on the LAN, similar to having monitors or iPads in your airline seat, all watching that gripping in-flight survival video. Such a setup could also be useful for a large school hall presentation, with monitors at the back of the room for example.
Naturally, using the VideoCore processor is the only realistic way to get good performance (I'm itching to get Wayland running) so I used "hello_video" from the
/opt/vc/src/hello_pi /hello_video
directory.
If you've never used hello_video before, you'll need to compile it. Ensure that Makefile.include is inside the "hello_pi" directory. I didn't want to rebuild everything, just hello_video.
So, type
make
at the $ prompt & a hello_video.bin executable file will be produced in the same hello_video directory.
If all you want is Camera-Pi to other Pi streaming, you can just use netcat (nc) thus from the RPi with camera:
On the receiving RPi:
pi@raspberrypi /opt/vc/src/hello_pi/hello_video $ nc -l -k 8080 | ./hello_video.bin /dev/stdin
Note that no IP is required here, just the same port that you'll stream from, & that also I used -k
-k isn't essential, but I find it very useful as the last image received, before the source stops transmitting, remains on screen at the receiving monitor. Handy to catch the perpetrator who's just unplugged your surveillance camera
EDIT: Today's rip-update has changed the way the raspivid executable interprets the time value. I've been using -1 for several days, but you need to revert to an unsigned value, say 999999 for the update. Should you want to try these statements on the existing firmware, -1 will be fine.
Now on Camera Pi:
pi@raspberrypi $ raspivid -t -1 -hf -o -| nc 192.168.1.107 8080
ensuring you replace my LAN IP & port with your own choice.
The latency & video quality in this setup is vastly better than using vlc, et al, & in line with jamesh's experience, & bear in mind I'm transmitting the full image, not a cut down version. Most of my testing is done using ethernet, but the above setup was fine during a few minutes testing with a receive RPi on a wifi dongle.
The next phase was to try broadcasting RPi camera to several receiver RPi's. Well, I did try netcat, but no joy
I'm no networking expert, so if any of you know how to use it for such, please report back.What does work however (again after much trial & ERROR) is socat
sudo apt-get install socat
as always to install a new application. Next from the CameraPi:
pi@raspberrypi $ raspivid -t -1 -hf -o -| socat - udp-datagram:192.168.1.255:8080,broadcast
Here you'd need to substitute the first 3 IP decimal values with your own, leaving the 255 as it is (unless you need thousands of monitors of course
)& on the receiving RPi:
pi@raspberrypi /opt/vc/src/hello_pi/hello_video $ socat - udp-recv:8080,reuseaddr | ./hello_video.bin /dev/stdin
Certainly in my tests, the Camera Pi almost saturates the LAN when broadcasting, to the extent that other computers can't get in easily. Interestingly no perceptible errors, so I imagine the recent USB improvements have helped a lot. I'm just hopeful my DVB-T2 tuner will work properly soon
So far I've used 3 RPi's in the broadcast setup, all on ethernet. I need more Pi's to test further
Hopefully I can demonstrate the setup at the MK jam on Sunday.I briefly tried a wifi dongle, but no joy on the broadcast setup, so I need to investigate that, but I thought it worth posting my findings on the off chance it may be interesting to others.
Now I need to mux in some audio channels to the stream
