1. mjpeg-streamer no longer works with the camera I bought because that camera only support YUYV, not JPEG or MJPEG. Switching to a Logitech camera allows mjpeg-streamer to start.
2. When mjpeg-streamer is killed the /dev/video0 port is no longer usable. You have to unplug the camera and plug it back in to use it again.
3. Even after addressing these issues omxplayer doesn't display anything.

Some of this may be problems in v4l2 in the kernel I'm using (4.9). I may need to bump to 4.14 and see if that helps first.

The unusable video port problem shows up with ffmpeg as well. There is a possible fix: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=197089
It involves making sure the following are added to cmdline.txt: dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3 (or possibly just dwc_otg.fiq_fsm_mask=0x3)

• https://github.com/ccrisan/streameye
• https://motion-project.github.io/
• https://github.com/ipartola/hawkeye
• https://github.com/cvsandbox/cam2web

Streameye seems to be what Raspbian is using these days, I think. Motion might be overkill. Hawkeye seems like a stripped down mjpeg-streamer. Haven't looked much as cam2web yet.

Streameye tests¶

This utility uses ffmpeg as a front end for video capture, piping the video to streameyey with this command.

ffmpeg -f video4linux2 -i /dev/video0 -r 30 -s 640x480 -f mjpeg -qscale 5 - 2>/dev/null | streameye

This works and omxplayer can play it, but frame rates are terrible on the console because both omxplayer and ffmpeg are battling for the CPUs on a RPi2. To get around this we can hardware accelerate both. omxplayer uses it's own ffmpeg libraries which can be hw accelerated using a custom Makefile.ffmpeg in the PiBox omxplayer metabuild. However, if you do this then ffmpeg stops working because the library loader path uses omxplayer's libs instead of the ffmpeg libs installed as part of the core platform. To get around this you just prefix the above command with LD_LIBRARY_PATH=/usr/lib.

However, this doesn't really improve things because the core platform ffmpeg is not hardware accelerated. To fix that I need to create a metabuild for ffmpeg that can apply similar Makefile fixes as was done to omxplayer's version of ffmpeg. Then ffmpeg can be hardware accelerated.

This is all good, but I don't really like this solution simply because I have to pipe ffmpeg to streameye, which I don't really want to do as an external command launched by picam. I'd rather have a single command, as I did with mjpeg_streamer.

Hawkeye works much better than mjpeg-streamer. It has no lag on my home network when the stream is played on my desktop. mjpeg-streamer has terrible lag. So I'm switching to hawkeye. The url has to be the following:

http://<ipv4 of node>:8080/stream/

Unfortunately, omxplayer will not play the stream at all. So I have no local player unless I build a browser, and that means building WebKitGTK+, which is so much overkill. Fortunately, I can stream the camera to a browser using the old PHP code, so I just need to make sure that's running along side the NodeJS server.

1. Test picam with hawkeye on Pi3. If this works at all, then PiCam can stay and this issue can be closed.
2. If that doesn't work, remove PiCam from the media server apps meta build. Webcam support will be moved solely to the web interface.

No difference on Pi3 - omxplayer just isn't playing the stream anymore. I don't know why. But for now, just skip it.
Removing from metabuild.

Both repos config files are updated, committed and pushed. The changes were manually tested on both RPi 2 and RPi 3.
Closing issue (finally).