Home > linux, software > VLC mpjpeg streaming

VLC mpjpeg streaming

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. :-(

Categories: linux, software Tags: , ,
  1. July 14th, 2009 at 23:13 | #1

    Hi,

    Out of curiosity: did you test this also with VLC 1.0 ? Would be interesting to see if the latest release actually suffers from this. And if so, it should be reported :-)

  2. pasky
    August 11th, 2009 at 14:03 | #2

    @Dominique Leuenberger

    I didn’t have that version handily available, so I didn’t… If anyone wants to test and report, they are welcome. :-)

  3. user
    June 6th, 2014 at 17:51 | #3

    thank you so much for the http hint (http{mime=multipart/x-mixed-replace; boundary=-…). still not fixed in vlc! So again, thanks alot!

  4. May 29th, 2015 at 23:04 | #4

    Great article.

  1. No trackbacks yet.


five + = 8