WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Camera Module  (Read 17086 times)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11041
Re: Camera Module
« Reply #15 on: January 27, 2015, 04:41:06 AM »
Well, he could program it so that the couple seconds is kept in RAM, and SD is only touched when saving.
The only barriers that can stop you are the ones you create yourself.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: Camera Module
« Reply #16 on: January 27, 2015, 06:25:49 PM »
That's pretty much the direction I've decided to go. I'll need to hack raspivid by adding a switch that basically says "record a window around an event like a SIGUSR1 and send me the file name in stdout". How hard can it be?

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: Camera Module
« Reply #17 on: January 31, 2015, 08:05:01 PM »
FWIW, I got it working by doing this:

set clipid [open "|raspivid -n -v -h 300 -w 400 -fps 10 -rot 180 -g 2 -sg 1000 -sn 001 -wr 300 -t 0 -pf baseline -o clips/vid%03d.h264 </dev/zero 2>@1"]

Then later I do this:

exec -ignorestderr -- cat $cfilea $cfileb $cfilec | ffmpeg -r 10 -i - -vcodec copy $vidid >/dev/null 2>/dev/null &

once I know which three clips I need. FFmpeg seams like a BFH for just concatenating three files and putting some mp4 information along with them. Is there a lighter faster way?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11041
Re: Camera Module
« Reply #18 on: February 01, 2015, 04:39:56 AM »
Only some codecs/containers support direct catting. Ogg Theora is one.
The only barriers that can stop you are the ones you create yourself.

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #19 on: February 04, 2015, 10:32:13 PM »
This is one of several posts that mentions the creation of a udev rule for the vchiq device to relax the permissions a little.  I did it like this on my picore 6.0 tonight and it seems to work fine to allow default tc user to use raspistill/raspivid without sudo.

Code: [Select]
tc@box:/opt$ cat /etc/udev/rules.d/10-vchiq-permissions.rules
SUBSYSTEM=="vchiq",GROUP="staff",MODE="0660"

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #20 on: February 09, 2015, 09:49:12 PM »
I noticed there was a small change to the raspicam source code on github so I thought I would recompile it and make another extension just for the practice.  There are precompiled binaries there too which I tried the first time around but the first one I tried wouldn't run (raspistill) - it gave me a "file not found" message which I didn't really investigate at the time, just moved straight to compiling from source.

So now I'm a little confused.  I've got three raspistill binaries on my pi, the first is loaded from the extension I originally made several weeks ago and was compiled from source available at the time. The next is in the build directory I used to compile from the updated source a couple of days ago.  The last is an already compiled binary I downloaded from the raspberry pi section on github.

All three are slightly different sizes, 111.8k, 108.4k, and 113.8k.

They all say when executed:
raspistill Camera App v1.3.8

The precompiled binary has a different interpreter file (ld-linux.so.3) which didn't exist on my system so I symlinked to the ld-linux-armhf.so.3 file used by the other binaries in order to get rid of the "file not found" message when trying to execute it (which I suspect was the problem I had originally several weeks ago).

- Why are the file sizes different?  Slightly different source? Different compiler options?  Both?
- Why are they all v1.3.8 when I know for at least two of them that the source had changed between compilations?
- Which would be better to use in the tcz, the one I compiled from source or the precompiled one?  I'd need to put a symlink for /lib/ld-linux.so.3 ---> /lib/ld-linux-armhf.so.3 in the extension to get it to work.

I know it's probably not a huge deal, just trying to learn something along the way and understand best practices...

//edit - also the "into the core" book mentions to strip debugging symbols to make the binary smaller - is that applicable to arm also and if so is it done at compile time or after the fact? 


Code: [Select]
tc@box:~$ file /tmp/tcloop/raspicam/usr/local/bin/raspistill
/tmp/tcloop/raspicam/usr/local/bin/raspistill: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, not stripped

tc@box:~$ file /mnt/mmcblk0p2/userland/opt/vc/bin/raspistill
/mnt/mmcblk0p2/userland/opt/vc/bin/raspistill: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, not stripped

tc@box:~$ file /home/tc/raspistill
/home/tc/raspistill: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.1.9, not stripped
« Last Edit: February 09, 2015, 09:56:40 PM by sodface »

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #21 on: February 16, 2015, 08:07:58 PM »
I've been experimenting (struggling!) with video streaming on PiCore6 and for the record have managed to get the following working, both using gstreamer:

UDP unicast:
On the Pi
Code: [Select]
gst-launch-1.0 rpicamsrc ! 'video/x-h264, width=1280, height=720, framerate=30/1,profile=high' ! queue ! rtph264pay ! udpsink
host=192.168.1.2 port=5000

gstreamer windows version on the receiving side
Code: [Select]
gst-launch-1.0.exe udpsrc port=5000 caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string) H264" ! rtph264depay ! decodebin ! autovideosink

And then using the gstreamer gst-rtsp-server (which seems far more useful than the unicast method):
Code: [Select]
./test-launch '( rpicamsrc vflip=true ! video/x-h264, width=1280, height=720, framerate=30/1,profile=high ! queue ! rtph264pay config-
interval=1 name=pay0 pt=96 )'

I tested the rtsp stream with vlc on windows and with rtsp player on android.  All testing done locally via wifi.  Worked ok, windows performance was better than android.  Need to keep working it.  For both methods I used the gstreamer and base plugins from the repo and compiled rpicamsrc, selected modules from from gst-plugins-good and gst-rtsp-server from source.


Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #22 on: February 24, 2015, 12:11:14 AM »
Another quick update on steaming, this time using mjpeg.  I made another raspicam extension using Silvan Melchior's userland source which includes the raspimjpeg command as well as raspistill, raspivid, and raspiyuv.  Then I made a small extension with the bare essentials from mjpg-streamer.

The immediate goal was to get a stream going that worked in a browser without plugins and required only minimum extensions on the pi, no apache, no php etc.

Load raspicam_sm.tcz and mjpegstream.tcz.

Start raspimjpeg and then mjpg-streamer and then goto {your.pi.ip.addr}:8080 in a browser (tested in chrome) to see the stream.

Code: [Select]
tc@box:/tmp$ sudo raspimjpeg &
tc@box:/tmp$ MJPEG streaming, ready to receive commands

tc@box:/tmp$ mjpg_streamer -i "/usr/local/lib/input_file.so -f /dev/shm/mjpeg -n  cam.jpg" -o "/usr/local/lib/output_http.so -w /var/www"
MJPG Streamer Version: svn rev:
 i: folder to watch...: /dev/shm/mjpeg/
 i: forced delay......: 0
 i: delete file.......: no, do not delete
 i: filename must be..: cam.jpg
 o: www-folder-path...: /var/www/
 o: HTTP TCP port.....: 8080
 o: username:password.: disabled
 o: commands..........: enabled

The newer versions of raspimjpeg use a configuration file hard coded to be located at /etc/raspimjpeg.  The extension linked above includes this file.   I was reading the core book on extension making but need to better understand what to do with config files so they are writable and you are able to save changes without having them overwritten the next time you load the extension.  I think as the extension is now you won't be able to have changes persist in /etc/raspimjpeg - haven't really tested it yet.

raspimjpeg is used in Silvan Melchior's RPi_Cam_Web_Interface application but it has a lot of features and needs php and apache (though people have used it with nginx also).  I wanted to just strip out the raspimjpeg binary but it still requires the /etc/raspimjpeg config file and needs some directories to exist when it starts so the extension creates them:
Code: [Select]
mkdir -p /var/www/media
mkdir -p /dev/shm/mjpeg
mknod /var/www/FIFO p
chmod 666 /var/www/FIFO

The mjpegstream extension just includes the mjpg-streamer binary, input_file.so and ouput_http.so libs and a simple index.html that sits in /var/www as that was the default path that the raspimjpeg config file defined.

So anyway, not sure if this is of any help or use but I was looking for a minimal / no bells or whistles way to do a basic stream to devices that already have a browser and wouldn't have to install anything else.   raspimjpeg is pretty cool as it uses the /var/www/FIFO pipe to take commands.  One command is "an" which changes the text annotation that is overlayed on the stream.  Right now that is defined in the /etc/raspimjpeg config file but can be changed on the fly by sending the command and the new text.  I'm going to try a cron job that runs my script to get the temperature from my w1 sensor every couple of minutes and update the stream annotation with that.

Work in progress...

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #23 on: February 26, 2015, 09:32:45 PM »
Updated and replaced the raspicam_sm.tcz file so that the raspimjpeg config file is writable and is in /usr/local/etc with a symlink created in /etc.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: Camera Module
« Reply #24 on: March 01, 2015, 11:15:55 PM »
I don't suppose you have one built for Pi 2? Otherwise can you tarball up your files and I can build it for arm7?

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #25 on: March 02, 2015, 07:22:19 AM »
I don't suppose you have one built for Pi 2? Otherwise can you tarball up your files and I can build it for arm7?

I thought the armv6 extensions would work on the rpi2?  I can make the files available though it might be better to just grab the updated source yourself?  Let me know if you want the official userland (at the time) or the Silvan Melchior one with raspimjpeg or both.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: Camera Module
« Reply #26 on: March 02, 2015, 07:34:00 AM »
The files with the mjpeg updates. I might try to use it to make the clips I need instead of using ffmpeg to assemble short clips into one longer one, so it seems that you have what may be the best starting point. It might be cleaner for what I need. Yes, I vaguely remember trying an older version of raspicam on my Pi2 and it working, so that's not the issue.

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #27 on: March 02, 2015, 08:53:48 AM »
andyj, here's the userland-master-SM source.  The build sub directory I created as the target for the binaries.

This is the mjpg-streamer source, not sure if you wanted that too.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: Camera Module
« Reply #28 on: March 02, 2015, 07:45:18 PM »
Thanks for the files. I changed /opt/vc to /usr/local, installed to /tmp/raspicam-v7, deleted the include, share, and src directories, added etc/udev/rules.d/10-vchiq-permissions.conf, but I couldn't find the raspimjpeg config file to put in usr/local/etc. I made the extension without it and it takes h264 video, but I haven't tried the mjpeg yet. What is this mjpeg config file?

Offline sodface

  • Jr. Member
  • **
  • Posts: 90
Re: Camera Module
« Reply #29 on: March 02, 2015, 08:20:16 PM »
/etc/raspimjpeg config file is here.

If you look at the source for raspimjpeg here, you can see it's looking for the config file at /etc/raspimjpeg.  I put the file in /usr/local/etc and a symlink to it in /etc, not sure if that was the best way to handle it or not.