Pasky’s Log

Last weekend, we were streaming four webcams from internal LAN behind firewall to the internet; the webcams were giving the stream as multipart jpeg and we wanted the stream at the internet to be multipart jpeg as well – it is not very effective, but the webcams aren’t high FPS and you can easily watch the stream in any browser.

You need a Linux system A in the LAN network, and publicly accessible Linux server B on a thick line at the internet (Windows should work too, but I didn’t test it). You need VLC 0.9.x (important! 0.8.x has mpjpeg streaming broken) installed on both.

On the A system, for each camera run:

while true; do \
  vlc -I dummy -vvv \
  'http://10.92.8.74/axis-cgi/mjpg/video.cgi?camera=1&resolution=352x288' \
  --sout '#es{access-video=udp,mux-video=ts,dst-video=62.24.64.27:9991}'; \
  sleep 1; done

(adjust URL for camera stream, IP address for B Linux server; hostnames mysteriously don’t work sometime!).

On server B, for each camera run:

while true; do \
  vlc -vvv udp://@62.24.64.27:9991 --sout \
  '#standard{access=http{mime=multipart/x-mixed-replace; boundary=--7b3cc56e5f51db803f790dad720ed50a},mux=mpjpeg,dst=62.24.64.27:8881}' \
  sleep 1; done

Then, connect with your browser to http://62.24.64.27:8881/. If the stream gets stuck, hit reload. For multiple cameras, just use port numbers 9992 and 8882 etc.

It’s a shame that you have to manually specify this magic to have browsers understand VLC-generated mpjpeg stream… I hope someone fixes this in future releases; in theory looking at the code it should work, but somehow something overrides the MIME type to application/octet-stream.

No re-encoding is done, you get the original quality as with the original stream. Unfortunately, the scheme doesn’t deal well with too thin uplink, if you fill your bandwidth from A to B, you don’t get dropped frames but completely corrupted stream. :-(