One of the ways we're generating additional interest in the mesh and our weather camera project is to push images to a website. Weather Underground provides a nice ftp service, and since one of our cameras is co-located with a Davis weather station (fed to a pi, also on the mesh!), we're ftping an image to there every 3 minutes during the day, and every 30 minutes at night.
We're grabbing the images from the rtsp stream using avconv on a pi.
/usr/bin/avconv -y -loglevel debug -rtsp_transport tcp -i "rtsp://kg9dw-qth-cam.local.mesh:554 //user=USER_password=PASSWORD_channel=1_stream=1.sdp"
-q:v 9 -vframes 1 kg9dw.jpg
Of course, change your rtsp address, user, and password to fit your needs. You can Google details on loading avconv to your pi load (it's painless).
FTPing in a shell script is just as painless:
USER='user'
PASSWD='password'
HOST='hostname.domain.org'
FILE='kg9dw.jpg'
/usr/bin/ftp -v -n $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASSWD
binary
lcd /tmp
put $FILE
quit
END_SCRIPT
exit 0
Happy meshing.
KG9DW
Maybe this will also help someone:
On my RPI (Raspberry Pi) here, I have two crontab scripts that do the following:
==> Every 5 minutes: The RPI will run a script that will grab a JPG frame from a remote (Hosafe) rtsp stream. Name each JPG with the current date/time. Add each acquired JPG to a running accumulator.tar file. The individual JPGs are availabe for view on my RPI web page. Alternately, one could download the accumulator.tar and have all the JPGs to date (just for one day) for viewing on their PC. That accumulator.tar is also available on the web page. There is a note on the web page suggesting that '7zip' is a tool that can be installed on a Windows PC that can easily extract all the JPGs from the accumulator.tar file.
==> At 11:59 PM every night: The RPI will run a second script that will place all the acquired JPGs for the day, into a single tar file with the name that is the date of all the JPGs. The script also removed the acumulator.tar so that can begin accumulating from scratch for the new day.
One thing to note is that not all grabbed frames (JPGs) are of perfect quality. Roughly 5-10% of them may have obvious corruption as seen with a viewer on the PC (I use Faststone viewer). I am guessing that is corruption from the 2-hop link from my QTH to the actual camera. That's roughly 2.5 miles plus 12.6 miles. Also a more general comment is the summer night captures as usual show a lot of (QRN?) interference mostly from spider webs! The day shots look nice and I have made lime-lapse movies from them.
Also, regarding the corrupted JPGs, I tried to use a Linux utility (can't remember its name) to automatically analyze and detect corruption it it didn't detect the bad JPGs. Since I can easily review, find and move the bad JPGs with Faststone, I gave up pursuing an automatic method.
Everything I did is a bit of a hack but seems to work well and has been running solidly every day for over a month. This whole thing was/is a bit of an experiment but is still interesting. I get rid of the corrupted JPGs on the PC then zip up by day and put into a 'history' directory on the RPI that is also accessible from the web page. FYI, I use MobaXterm to move files back and forth between my RPI and Windows 7 PC. Below are the scripts and crontab information.
================================
crontab for 1st script:
*/5 * * * * /home/pi/bin/joe's-hosafe-cam1-2jpg.sh
================================
CONTENTS OF joe's-hosafe-cam1-2jpg.sh:
#!/bin/bash
today=`date '+%Y_%m_%d__%H_%M_%S'`;
filename="/home/pi/Videos/joes-hosafe-cam1/$today.jpg"
shortfname="$today.jpg"
avconv -i rtsp://joes-hosafe-cam1.local.mesh:554/ -r 1 -vframes 1 -vsync 1 -qscale 1 -f image2 $filename
tar --append --file=/home/pi/Videos/joes-hosafe-cam1/0-acumulator.tar -C /home/pi/Videos/joes-hosafe-cam1 $shortfname
================================
crontab for 2nd script:
59 23 * * * /home/pi/bin/tar-joe's-hosafe-cam1.sh
================================
CONTENTS OF tar-joe's-hosafe-cam1.sh:
#!/bin/bash
cd /home/pi/Videos/joes-hosafe-cam1/
NOWDATE=`date +%Y-%m-%d`
tar --remove-files -cvf $NOWDATE.tar ./*.jpg
rm /home/pi/Videos/joes-hosafe-cam1/0-acumulator.tar
================================
73 - Mike ab4yy
https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%...
(I Frames are complete frames, not dependent upon data before or after the frame, they contain a complete frame and as such should not have any artifacts )
kg9dw - it seems like there's a missing " in this??
/usr/bin/avconv -y -loglevel debug -rtsp_transport tcp -i "rtsp://kg9dw-qth-cam.local.mesh:554//user=USER_password=PASSWORD_channel... -q:v 9 -vframes 1 kg9dw.jpg
I've added a carriage return so that it posts correctly on the forum. When displayed, the forum code is truncating the long link with ...
The first post is now correct. Thanks!
I have two identical cameras (both HOSAFE).
This WAS working on the one with no user/password configured: It stopped working with the same error shown below.
/usr/bin/avconv -y -loglevel debug -rtsp_transport tcp -i "rtsp://w6bi-simicam1:554//channel=1_stream=1.sdp" -q:v 9 -vframes 1 /tmp/w6bi-simicam1.jpg
I have another one that is configured with userid & password "view"
This is what I'm trying:
/usr/bin/avconv -y -loglevel debug -rtsp_transport tcp -i "rtsp://w6bi-drivewaycam-rtsp:554//user=view_password=view_channel=0_stream=0.sdp" -q:v 9 -vframes 1 /tmp/w6bi-drivewaycam.jpg
I've tried all four combinations of channel & stream, and they all result in
Invalid data found when processing input
Any suggestions?
Thanks.
I don't know the answer but a Google search (avconv Invalid data found when processing input) brings up quite a few results. This one may be worth trying: http://stackoverflow.com/questions/35866447/ffmpeg-invalid-data-found-when-processing-input-h264-to-h265
See answer #2 with the green check mark....
This worked for him ("Try including the following to correc that: "-flags +global_header".").
If that doesn't help, I'd check out further Google search results.
- Mike ab4yy
Thanks
avconv seems to be discontinued... try ffmpeg
it works for me in http://iz5fsa-server.local.mesh/webcams.html
https://shinobi.video/
I'm pretty sure shinobi is actually using ffmpeg under the hood.
Oh, and also, incase it is useful for someone, you can also use vlc (or shinobi) to transcode video, for example from rtsp to an mjpeg video stream, so that it can be directly streamed on a webpage with the html5 <video> tag. Ie, instead of getting static images, to get live video streaming. (Obviously this uses more processing power.)
192.168.10.211 is the ip address of the camera, and 8881 is the port of the computer vlc is running on that the mpeg4 video stream will be hosted on.
and then in the webpage:
192.168.10.13 is the ip address of the computer that VLC is transcoding on and 8881 is the port in the script above.
Note that I have three cameras and one vlc process running per camera, and each one needs its own port.
https://github.com/Motion-Project
I use the basic functionality of the program, I could relay other RTSP streams like https://github.com/aler9/rtsp-simple-server. I use it to serve up a rtsp stream and snapshot. One could use any RTSP stream, RPiCamera, USB camera or in my case usb attached DSLR.
xterm -e "gphoto2 --stdout --capture-movie | ffmpeg -i - -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video0" &&
I upload the periotic snapshot via ftp after I wget the rest of the cameras.