Pasky’s Log

We have our mice TV now streaming our colony of mus minutoides at the canonical URL http://mice.or.cz/ but it would be nice if you could watch them in your web browser (without flash) instead of having to open a media player for the purpose.

I gave that some serious prodding. We still use vlc with the same config as in the original post (mp4v codec + mpegts container). Our video source is an IP cam producing mp4v via rtsp and an important constraint is CPU usage as it runs on my many-purpose server (current setup consumes 10% of one CPU core). We’d like things to work in Debian’s chromium and iceweasel, primarily.

It seems that in the HTML5 world, you have these basic options:

• MP4/H264 in MP4 – this *does not work* with live streaming because you need to make sure the browser receives a correct header with metadata which normally occurs only at the top of the file; it might work with some horrible custom code hacks but nothing off-the-shelf
• VP80/VP90 in webm – this works, but encoding consumes between 150%-250% CPU! even with low bitrates; this may be okay for dedicated streaming servers but completely out of the question for me
• Theora in Ogg – this almost works, but the stream stutters every few seconds (or slips into endless buffering), making it pretty hard to watch; apparently some keyframes are lost and Theora homepage gives a caveat that Ogg encoding is broken in VLC; the CPU usage is about 30%, which would have been acceptable

That’s it for the stock video tag formats, apparently. There are two more alternatives:

• HTTP Live Stream (HLS) has no native support in browsers outside of mobile, might work with a hack like https://github.com/RReverser/mpegts but you may as well use MSE then
• Media Source Extensions (MSE) seem to allow basically implementing decoding custom containers (in javascript) for any codecs, which sounds hopeful if we’d just like to pass mp4v (or h264) through. The most popular such container is DASH, which seems to be all about fragmenting video to smaller HTTP requests with per-fragment bitrate negotiation, but still completely codec agnostic. Re Firefox, needs almost latest version. Media players support DASH too.

So far, the best looking courses seem to be:

• Media server nginx-rtmp-module (in my case with pull directive towards the ipcam’s rtsp) with mpeg-dash output and dash.js based webpage. I might have misunderstood something but it might actually just work (assuming that the bitrate negotiation could always end up just choosing the ipcam’s fixed bitrate; something very low is completely sufficient anyway).
• Debug libogg + libtheora to find out why it produces corrupted streams – have fun!

Chido has two mouse-pets (Acomys Caihirinus, actually) and we finally did what we already planned to do long ago:

vlc http://pasky.or.cz:8090/mouses.flv

A live video stream of our mouse palace!

Some technical trivia – the IP cam used is Edimax IC-3110 (it’s pretty crappy, not recommended) and we are restreaming using vlc invocation:

cvlc -L --sout "#transcode{vcodec=mp4v,vb=1024,scale=1}:duplicate{dst=http{mux=ts,dst=:8090/mouses.flv},select=noaudio}" --no-sout-rtp-sap --no-sout-standard-sap --sout-ts-shaping=1000 --sout-ts-use-key-frames --ttl=40 rtsp://admin:PASSWORD@192.168.6.X:554/ipcam.sdp

(I did not get h264 FLV stream working reliably, unfortunately. I tried #transcode{vcodec=h264,venc=x264{keyint=20},vb=4096,scale=1} and duplicate{dst=http{mux=ffmpeg{mux=flv},dst=...,select=noaudio}.)

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