Project

General

Profile

Actions

Bug #628

closed

PiCam on console not working.

Added by Hammel about 4 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
04 - Applications
Target version:
Start date:
18 May 2018
Due date:
% Done:

100%

Estimated time:
Severity:
02 - High

Description

Running on PiBox Server 2 (RPi Model 2 B). The app starts but nothing is displayed.


Files

Makefile (3 KB) Makefile omxplayer updated for latest + hw accel Hammel, 02 Aug 2018 11:01
Makefile.ffmpeg (7.48 KB) Makefile.ffmpeg ffmpeg for omxplayer, updated for hw accel Hammel, 02 Aug 2018 11:01
Makefile.include (1.69 KB) Makefile.include Include file, updated for latest omxplayer Hammel, 02 Aug 2018 11:01
omx.cfg (1.78 KB) omx.cfg Bump to master for omxplayer git commit Hammel, 02 Aug 2018 11:01
Actions #1

Updated by Hammel almost 4 years ago

  • Severity changed from 01 - Critical to 05 - Very Low
Actions #2

Updated by Hammel almost 4 years ago

  • Severity changed from 05 - Very Low to 02 - High
Actions #3

Updated by Hammel almost 4 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
There are a couple of problems here.
  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)

These may have an impact on whether omxplayer will play the video as well, so I need to try that. If not, it may be time to find an alternative to mjpeg-streamer. Here are some options.

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.

Actions #4

Updated by Hammel almost 4 years ago

The fix for the device not ready problem (the changes to cmdline.txt) worked. I need to add that to the default cmdline.txt I use.

Actions #5

Updated by Hammel almost 4 years ago

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.

Actions #6

Updated by Hammel almost 4 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.

Actions #7

Updated by Hammel almost 4 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.

Actions #8

Updated by Hammel almost 4 years ago

Webcam support is not in imwww. Its only in the old piboxwww. I can port it, and then only enable it if not in config mode. Or I can try to port to NodeJS, which sounds harder.

Actions #9

Updated by Hammel almost 4 years ago

  • % Done changed from 30 to 60
I have two things left to do here.
  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.
Actions #10

Updated by Hammel almost 4 years ago

  • % Done changed from 60 to 80

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.

Actions #11

Updated by Hammel almost 4 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.

Actions #12

Updated by Hammel almost 4 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.

Actions #13

Updated by Hammel almost 4 years ago

Works on RPi 2 too. So all this just because the command had to change a little. Ah well.....

Still need to update the commands for piboxd and picam.

Actions #14

Updated by Hammel almost 4 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 80 to 100

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

Actions

Also available in: Atom PDF