PiCam on console not working.
|Status:||Closed||Start date:||18 May 2018|
|Category:||04 - Applications|
|Target version:||1.0 - Atreides|
|Severity:||02 - High|
Running on PiBox Server 2 (RPi Model 2 B). The app starts but nothing is displayed.
RM #628: Remove PiCam for now because the console camera just isn't working well enough to demo. We'll use web based cameras instead, which work fine.
RM #628: Set the proper command to use for mjpeg-streamer so it works right with recent versions of omxplayer on the console.
RM #628: Update omxplayer command for use with recent version of omxplayer (so it plays better on the console).
#3 Updated by Hammel about 2 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
- 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.
- 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.
- 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)
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.
#5 Updated by Hammel about 2 years ago
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.
#6 Updated by Hammel about 2 years ago
Hawkeye was easy to get cross compiled (I used the omxplayer Makefile.include as an template) and it works very well when you connect to it from the browser. Better than mjpeg-streamer did. This one is a likely replacement candidate for mjpeg-streamer. It does require the v4l2 package built into the core, however.
I think I mucked up the core platform and omxplayer package because omxplayer doesn't run at all now. So I need to reinstall that image, load hawkeye and then try it again to see how well console playback works.
I should also try this on the RPi 3 and see if it does any better.
Note: hawkeye is my work directory, where the modified src/Makefile and new src/Makefile.include can be found.
#7 Updated by Hammel about 2 years ago
- % Done changed from 10 to 30
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.
#9 Updated by Hammel almost 2 years ago
- % Done changed from 30 to 60
- Test picam with hawkeye on Pi3. If this works at all, then PiCam can stay and this issue can be closed.
- If that doesn't work, remove PiCam from the media server apps meta build. Webcam support will be moved solely to the web interface.
#11 Updated by Hammel almost 2 years ago
Ugh. One more data point: omxplayer does play the mjpeg-streamer content on Pi3 now. And it looks pretty good but buffers badly. I think the way to use picam is to have the player connect to a remote camera instead of one on the same board. Then it would work better on the console.
But that's more work than I need for this so I'm just going to stick to my plan of removing it from the media server for now, and leaving mjpeg-streamer in place for remote viewing via the web interface.
I'll create a separate issue to track changing the PiCam works.
#12 Updated by Hammel almost 2 years ago
Double ugh. I tried one more thing: adding --live to the omxplayer options. And bingo - it plays beautifully with mjpeg-streamer.
So here is the command that works for omxplayer:
xterm -display :0.0 -fullscreen -fg black -bg black -e omxplayer.bin --live --fps 10 -o hdmi -r http://192.168.101.17:9090/?action=stream
And here is the mjpeg-streamer command:
mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 640x480 -f 10" -o "output_http.so -p 9090"
Note that this was on an RPI 3. Need to test it on an RPI 2 to see if that will work as well. Otherwise, PiCam only demos on an RPi 3.
Now I just need to make sure I have the right commands configured and the right hardware in order to make PiCam work.