btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Sat May 02, 2015 9:05 am

xab wrote:
sknic wrote:Hi, I play with raspberry pi as cam using rpi cam web interface. Using default settings and watching live video from pi it consumes 18Mbit/s of bandwitch. This is pretty much and on mobile internet it is not possible. How to lower this bandwitch to 3Mbit/s? Thanks
Check /etc/raspimjpeg , find the line with "video_bitrate" and then modify the number, by default it should be 17Mbit/s ;)
video_bitrate can also be set from the web interface under camera settings. For most purposes it can be lowered down to 3Mbit/s. You can also edit the default in the /etc file if required.

However this bit rate affects video recordings and their playback from the download screen. It does not affect the live video main screen as this is obtained from the mjpeg feed.

There are a number of factors affecting the live previews; width, divider, quality. These can all be controlled from the web interface. In addition you can choose between default streaming where it is fetching a sequence of jpegs or a true mjpeg stream. This doesn't fundamentally change the bandwidth but the mjpeg stream has less to and fro with the web server so may be smoother.

Width controls the size of the mjpeg images generated and will have a significant impact on bandwidth. It also controls the size on the display. By default it is 512px. If you can live with say 384 then that should halves the bandwidth.

Quality is the jpeg compression factor (0-100). Lower numbers give better compression at the expense of quality. It is set to 25 by default which gives pretty good compression and not too much degradation. YOu could try lowering it to say 15 which will significantly lower sizes further but you will start to see some degradation. Lowe than this it will start to get bad.

Divider is the rate at which new data is fetched. It is the video fps (default 25) divided by 'Divider'. Nominally that would mean it is trying to update at 25fps but in practice other delays lower this a bit. Increasing the divider lowers the fetch frame rate so 3 would give a nominal rate of 8fps. This will also have a dramatic effect on bandwidth.

Edit: Using width=384, Q=15, Divider=3 I got about 1.5Mbit/s usage

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Sat May 02, 2015 3:14 pm

btidey wrote:
solar3000 wrote:I was just concerned that this program runs as root and that it creates files as root.
Would there be any security concerns?
I was thinking of opening a port to this web interface program.
I've had a go at changing the install / start up and it seems to work. It ends up with raspimjpeg running as www-data (the apache default user) and the media files are stored as www-data.

I have not updated the Git yet as I want to give it a bit longer to make sure it's running OK.
I haven't seen any problems running under www-data so I have now pushed the changes to the repository. After a reboot raspimjpeg should be running as www-data and captured files are owned by www-data.

Edit: I think the scheduler has lost the ability to stop the background version of itself from the web interface. I'm looking at that but it doesn't impact on normal operation.

Edit2 I think this was only a problem after doing stop start of th ewhole process from installer script. I think it is fixed now.

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

latest version broken?

Sun May 03, 2015 1:56 am

How can I install the previous version? This one is only partly working (live view but no record).

After loading this last update (raspimjpeg running as www-data) the web interface comes up and the live preview shows up, but I cannot get the top row of buttons to work (eg. record video start, record image, motion detection start, etc). I completely uninstalled, reinstalled and rebooted but no luck. I also tried uninstall, reboot, reinstall, reboot. The second row of buttons (download, motion settings, schedule settings) does work. After startup, the log says:

Code: Select all

{2015/05/02 19:04:30} Motion detection started
{2015/05/02 19:04:31} SIGINT/SIGTERM received, stopping
{2015/05/02 19:04:43} RaspiMJPEG Version 5.1.3
{2015/05/02 19:04:43} MJPEG streaming, ready to receive commands
[2015/05/02 19:04:47] RaspiCam support started
[2015/05/02 19:04:48] Capture Pipe already exists /var/www/FIFO1
[2015/05/02 19:04:48] Scheduler loop is started
[2015/05/02 19:04:49] New period detected 0
[2015/05/02 19:04:49] Scheduled management tasks. Next at 1430622289
also, in /var/log/syslog I get many repetitions of motion trying to open /dev/video0

Code: Select all

May  2 19:26:00 rp21 motion: [1] Retrying until successful connection with camera
May  2 19:26:00 rp21 motion: [1] Failed to open video device /dev/video0: No such file or directory
I see that 'motion' is running as www-data but /etc/motion/motion.conf is (own/grp) root / motion and -rw-r----- so the www-data group can't even read it, that seems like a problem?

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RPi Cam Web Interface

Sun May 03, 2015 2:42 am

After doing this:

Code: Select all

 sudo chgrp www-data /etc/motion/motion.conf
 sudo chmod +rrr /etc/motion/motion.conf
the motion process runs, and it also properly triggers a recording on motion. Initially, none of the top row of buttons worked (eg. motion start/stop) but after some time, they started working (maybe a browser refresh problem).

Another issue: motion settings cannot be changed from the web page ("save" with new settings just reverts to old setting). Manually editing /etc/motion/motion.conf does work, of course.

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Sun May 03, 2015 7:51 am

btidey wrote:
johng wrote:I am still getting iframe errors on two installations notwithstanding that I am running 5.1.3 with buffer set to 4000 on both.

It looks as if there is some logging error at line 637, incomplete line.

Curiously, although buffer is showing as 4000 on both browser screens under camera settings (and remains at 4000 after reboot), raspimjpeg is showing 3000 on one machine and 0 on the other under setting video_buffer. Is video_buffer the same as buffer under camera settings and if so should I change video_buffer manually?

John G
The screwed up logging there is a consequence of the iframe errors being logged from within the callback function from the camera system when it returns each buffer of data. This is asynchronous to the main raspimjpeg process and so if the foreground process happens to be logging an event at exactly the same time then they can clash and a bit can get lost. We could do something about this but the logging from the callback is really just for gross errors like these iframes, so it is better to fix those rather than worry about this bit.

Certainly setting buffer up helps to avoid these and I find with > 3000 I rarely get them. There have also been some improvements in the buffer handling which should help avoid these but these are in the branch of code for motion vector handling so isn't ready for main use yet.

The buffer size is almost certainly correct on the web interface. The reason why you see a 'difference' is because there are 2 raspimjpeg config files. The one in /etc is the factory defaults that you can also edit to change the basic defaults. The other is the uconfig file held in /var/www which holds any changes you have made from the web interface. raspimjpeg reads the default one first then it reads uconfig which can update any values it holds. So for example if you have video_buffer 3000 in /etc/raspimjpeg then make a change from the web to 4000 then you will find video_buffer 4000 in uconfig and that will be the active one. By doing a reset settings from the web uconfig is wiped and all values then revert to the factory defaults.
Many thanks for your quick reply and apologies for my slow one - family arrived for holiday weekend.

I should have thought of uconfig! Checked it and they both show 4000. Many thanks.

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Sun May 03, 2015 7:56 am

jbeale wrote:
johng wrote:2. I am slightly confused as to how to update the software to the latest vesion. if I re-install using git clone https://github.com/silvanmelchior/RPi_C ... erface.git, it demands that I delete the Rpi_Web_Cam_Interface directory. Is this right or is there a simpler way. I think I saw somewhere that there is an update or upgrade parameter I can use instead of new instal. If there is, does it overwrite config files?
I don't execute any git commands, I just navigate to the directory and do

Code: Select all

./RPi_Cam_Web_Interface_Installer.sh install
That automatically updates to the latest version from github, stops the current running raspimjpeg process, and then re-installs. Afterwards I usually reboot although not sure if necessary.
Many thanks for quick reply and apologies for my slow one; family arrived for holiday weekend...

That's much simpler - thanks, will do.

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Sun May 03, 2015 8:10 am

btidey wrote:
johng wrote:A couple of queries:-

1a. is it possible to put additional commands into the motion on_event_start and on_event_end settings? I am currently running a pi with the standard motion mmal and using these settings to communicate motion on and off to Domoticz so that I can trigger other actions but I would like to move to using RPI Cam Web for this.

1b. Following on from this, I see that there is talk of changing away from motion. If this is achieved, will there still be a facility to notify external programs of motion events?


Many thanks, John G
Yes. You can currently put additional commands separated by ; into motion events.

I was a little bit uncomfortable with this myself as it means that any operating system command can be added from the web interface which is a bit dangerous from a security view.

That is why I have added the macros folder where one can put a limited set of commands (scripts) and only those can be selected for running from the web interface. These can be run either as the scheduler management_command or can be included in any of the scheduler motion trigger start stop or period entries.

You can do that even today instead of putting it in the motion set up and then it will still be applicable when motion is swapped out. So for example in a motion start box that currently has ca 1 you could put ca 1;sy notify.sh This will then start capturing video and will then try to run a script called notify.sh in the macros folder. You must create and put notify.sh in that folder first and give it execution rights. You have to do that outside of the web interface as the purpose is to lock down what can be run.
Thanks. Wonderful - exactly what I was looking for! I'll give it a try. It opens up all sorts of possibilities.

Totally agree on the security issue and the macros folder limitation is a good compromise.

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

pre-event video buffer: 9-second gap?

Sun May 03, 2015 6:19 pm

Under "Camera Settings" I have a buffer of 4000 msec, is that bad? Usually it works ok, but sometimes it doesn't. I suspect there is a problem when two video events happen close together in time.

Here is one example. Event 0059 ends at 10:57:38 and Event 0060 starts 4 seconds later, at 10:57:42. When I view the captured video #0060 at "preview.php?preview=vi_0060_20150503_105743.mp4.v0060.th.jpg" then I do see the video timestamp start at 10:57:39 and run through 10:57:44, but then it abruptly skips to 10:57:53 and runs to 10:58:16. So there was 9 seconds of real time starting at 10:57:45 that was not captured. Comparing with the log time reports, the video goes missing 2 seconds after the capture started, and then returns the same second that the boxing process completed for the previous video #0059. The boxing process is set to "Background" and this is on a 4-core Pi Model 2 so I'd think it would run independently.

The log file says this:

Code: Select all

[2015/05/03 10:57:28] Start capture requested
[2015/05/03 10:57:28] Send ca 1
{2015/05/03 10:57:28} Capturing started
[2015/05/03 10:57:38] Stop capture requested
[2015/05/03 10:57:38] Send ca 0
{2015/05/03 10:57:38} Capturing stopped
{2015/05/03 10:57:38} Add /var/www/media/vi_0059_20150503_105728.mp4 to Box Queue at pos 7
{2015/05/03 10:57:38} Start boxing /var/www/media/vi_0059_20150503_105728.mp4 from Box Queue at pos 7
[2015/05/03 10:57:42] Start capture requested
[2015/05/03 10:57:42] Send ca 1
{2015/05/03 10:57:43} Capturing started
{2015/05/03 10:57:53} Finished boxing /var/www/media/vi_0059_20150503_105728.mp4 from Box Queue at pos 7
[2015/05/03 10:58:17] Stop capture requested
[2015/05/03 10:58:17] Send ca 0
{2015/05/03 10:58:17} Capturing stopped
{2015/05/03 10:58:25} Add /var/www/media/vi_0060_20150503_105743.mp4 to Box Queue at pos 8
{2015/05/03 10:58:26} Start boxing /var/www/media/vi_0060_20150503_105743.mp4 from Box Queue at pos 8
{2015/05/03 10:58:42} Finished boxing /var/www/media/vi_0060_20150503_105743.mp4 from Box Queue at pos 8

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: pre-event video buffer: 9-second gap?

Sun May 03, 2015 9:26 pm

jbeale wrote:Under "Camera Settings" I have a buffer of 4000 msec, is that bad? Usually it works ok, but sometimes it doesn't. I suspect there is a problem when two video events happen close together in time.

Here is one example. Event 0059 ends at 10:57:38 and Event 0060 starts 4 seconds later, at 10:57:42. When I view the captured video #0060 at "preview.php?preview=vi_0060_20150503_105743.mp4.v0060.th.jpg" then I do see the video timestamp start at 10:57:39 and run through 10:57:44, but then it abruptly skips to 10:57:53 and runs to 10:58:16. So there was 9 seconds of real time starting at 10:57:45 that was not captured. Comparing with the log time reports, the video goes missing 2 seconds after the capture started, and then returns the same second that the boxing process completed for the previous video #0059. The boxing process is set to "Background" and this is on a 4-core Pi Model 2 so I'd think it would run independently.
Buffer of 4000 should be fine. I'm not sure why you are getting this. I use this all the time (on a B) and pretty much all the recordings are clean. I do occasionally get one when one can see a small glitch which correlates with the stitching of the buffer with the video. I don't see how boxing could be involved and I think it is more likely that something is getting screwed at the iFrame processing level.

There have been some improvements in how this works in integrated motion detect branch being worked on, so that should also help.

Please post again if you continue to experience this and how often.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Sun May 03, 2015 9:31 pm

While checking some other areas out I found some errors in setting up Region of Interest, but even with these corrected this function is still not working probably involving the low level camera interface.

I am guessing nobody is trying to use this so it is probably a low priority.

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RPi Cam Web Interface

Sun May 03, 2015 10:26 pm

The camera buffer is set at 4000 msec. Sometimes, but not always I am seeing a lot of this "iframe list" error repeated:

Code: Select all

[2015/05/03 14:02:15] Start capture requested
[2015/05/03 14:02:15] Send ca 1
{2015/05/03 14:02:15} Capturing started
[2015/05/03 14:02:19] Stop capture requested
[2015/05/03 14:02:19] Send ca 0
{2015/05/03 14:02:19} Capturing stopped
{2015/05/03 14:02:19} Add /var/www/media/vi_0111_20150503_140215.mp4 to Box Queue at pos 18
{2015/05/03 14:02:19} Error: Error in iframe list
{2015/05/03 14:02:19} Start boxing /var/www/media/vi_0111_20150503_140215.mp4 from Box Queue at pos 18
{2015/05/03 14:02:19} Error: Error in iframe list
{2015/05/03 14:02:19} Error: Error in iframe list
{2015/05/03 14:02:19} Error: Error in iframe list
{2015/05/03 14:02:19} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
{2015/05/03 14:02:20} Error: Error in iframe list
... and many more...

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

consecutive events too close = some lost recording

Sun May 03, 2015 11:07 pm

Another example of consecutive event issues, using a buffer of 3000 msec. Reviewing the timestamps on the .mp4 file afterwards, video 0158 has an actual start time 18 seconds before trigger. In video 0159 (starting 5 seconds after end of last event) the actual recorded video begins 8 seconds after the trigger. In the log, "Capturing started (15:42:56)" does not happen until after the "Stop capture requested (15:42:45)" line! I guess due to waiting for buffer to fill? But that didn't prevent losing 8 seconds of action after the trigger. Starting another video before the buffer is full is a tricky case, but I wonder if there is some way to avoid missing some of the video.

Code: Select all

Video 0158: event at 15:42:17, video timestamp runs from 15:42:09 to 15:42:35
Video 0159: event at 15:42:40, video timestamp runs from 15:42:48 to 15:42:56

[2015/05/03 15:42:17] Start capture requested
[2015/05/03 15:42:17] Send ca 1
{2015/05/03 15:42:17} Capturing started
[2015/05/03 15:42:35] Stop capture requested
[2015/05/03 15:42:35] Send ca 0
{2015/05/03 15:42:35} Capturing stopped
{2015/05/03 15:42:35} Add /var/www/media/vi_0158_20150503_154217.mp4 to Box Queue at pos 1
{2015/05/03 15:42:36} Start boxing /var/www/media/vi_0158_20150503_154217.mp4 from Box Queue at pos 1
[2015/05/03 15:42:40] Start capture requested
[2015/05/03 15:42:40] Send ca 1
[2015/05/03 15:42:45] Stop capture requested
[2015/05/03 15:42:56] Send ca 0
{2015/05/03 15:42:56} Capturing started
{2015/05/03 15:42:57} Capturing stopped
{2015/05/03 15:42:57} Add /var/www/media/vi_0159_20150503_154240.mp4 to Box Queue at pos 2
{2015/05/03 15:42:57} Finished boxing /var/www/media/vi_0158_20150503_154217.mp4 from Box Queue at pos 1
{2015/05/03 15:42:57} Start boxing /var/www/media/vi_0159_20150503_154240.mp4 from Box Queue at pos 2
{2015/05/03 15:42:58} Finished boxing /var/www/media/vi_0159_20150503_154240.mp4 from Box Queue at pos 2

fergusondavid6
Posts: 58
Joined: Sun Apr 21, 2013 3:36 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 9:02 am

Are you supposed to run the commands in the root directory, in /home/pi/ or in any directory of your choosing?

Thanks

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: consecutive events too close = some lost recording

Mon May 04, 2015 9:21 am

jbeale wrote:Another example of consecutive event issues, using a buffer of 3000 msec. Reviewing the timestamps on the .mp4 file afterwards, video 0158 has an actual start time 18 seconds before trigger. In video 0159 (starting 5 seconds after end of last event) the actual recorded video begins 8 seconds after the trigger. In the log, "Capturing started (15:42:56)" does not happen until after the "Stop capture requested (15:42:45)" line! I guess due to waiting for buffer to fill? But that didn't prevent losing 8 seconds of action after the trigger. Starting another video before the buffer is full is a tricky case, but I wonder if there is some way to avoid missing some of the video.

Code: Select all

Video 0158: event at 15:42:17, video timestamp runs from 15:42:09 to 15:42:35
Video 0159: event at 15:42:40, video timestamp runs from 15:42:48 to 15:42:56

[2015/05/03 15:42:17] Start capture requested
[2015/05/03 15:42:17] Send ca 1
{2015/05/03 15:42:17} Capturing started
[2015/05/03 15:42:35] Stop capture requested
[2015/05/03 15:42:35] Send ca 0
{2015/05/03 15:42:35} Capturing stopped
{2015/05/03 15:42:35} Add /var/www/media/vi_0158_20150503_154217.mp4 to Box Queue at pos 1
{2015/05/03 15:42:36} Start boxing /var/www/media/vi_0158_20150503_154217.mp4 from Box Queue at pos 1
[2015/05/03 15:42:40] Start capture requested
[2015/05/03 15:42:40] Send ca 1
[2015/05/03 15:42:45] Stop capture requested
[2015/05/03 15:42:56] Send ca 0
{2015/05/03 15:42:56} Capturing started
{2015/05/03 15:42:57} Capturing stopped
{2015/05/03 15:42:57} Add /var/www/media/vi_0159_20150503_154240.mp4 to Box Queue at pos 2
{2015/05/03 15:42:57} Finished boxing /var/www/media/vi_0158_20150503_154217.mp4 from Box Queue at pos 1
{2015/05/03 15:42:57} Start boxing /var/www/media/vi_0159_20150503_154240.mp4 from Box Queue at pos 2
{2015/05/03 15:42:58} Finished boxing /var/www/media/vi_0159_20150503_154240.mp4 from Box Queue at pos 2
Yes. There could be an issue with a new start request coming hard on the heels of a stop request.

The sequence is like you say.
The stop finishes up the file and kicks of the Mp4Box and then starts preparing the new video buffer. While doing this it is not looking at the input commands so your next start request at 15:42:40 is not getting processed until that has happened 16 seconds later. The discrepancy between the 4000 and 16 seconds is probably due to good compression as the buffer calculation is based on the nominal video_bitrate. I normally see a factor of between 2 and 3 times.

It is not clear to me at the moment why this causes a specific problem unless there is some minimum video length we need to record to file before adding the buffer and in this case the start stop are being processed very close together. We could try enforcing a minimum period between start and stop inside raspimjpeg.

On the iframe buffer errors this seems to come and go, although I rarely see them. I think it is associated with stop commands which have been reworked in the motion triggered development.

If you are getting such a long pre-trigger time for 4000 then it might be worth lowering to say 2000 for the moment.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 9:27 am

fergusondavid6 wrote:Are you supposed to run the commands in the root directory, in /home/pi/ or in any directory of your choosing?

Thanks
Assuming you are referring to the install commands on the wiki then you would normally run them from your home directory (/home/pi). After the updates and the git clone then you will find the RPi_Cam_Web_Interface folder created there.

In principle I believe you could start the git clone from any folder where you have normal read / write permissions like say /home/pi/camera but not from root.

johng
Posts: 41
Joined: Thu Apr 23, 2015 10:00 am

Re: RPi Cam Web Interface

Mon May 04, 2015 10:52 am

by jbeale » Sun May 03, 2015 2:42 am
After doing this:

Code: Select all
sudo chgrp www-data /etc/motion/motion.conf
sudo chmod +rrr /etc/motion/motion.conf

the motion process runs, and it also properly triggers a recording on motion. Initially, none of the top row of buttons worked (eg. motion start/stop) but after some time, they started working (maybe a browser refresh problem).

Another issue: motion settings cannot be changed from the web page ("save" with new settings just reverts to old setting). Manually editing /etc/motion/motion.conf does work, of course.
Many thanks for saving my sanity. I was having the same problems in 5.1.6 and when restarting in an SSH session it said couldn't open motion.conf, permission denied and then the /dev/video errors spewed down the screen.. Well found!
Confirm that motion settings aren't being changed from the web page in 5.1.6.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 3:18 pm

johng wrote:
by jbeale » Sun May 03, 2015 2:42 am
After doing this:

Code: Select all
sudo chgrp www-data /etc/motion/motion.conf
sudo chmod +rrr /etc/motion/motion.conf

the motion process runs, and it also properly triggers a recording on motion. Initially, none of the top row of buttons worked (eg. motion start/stop) but after some time, they started working (maybe a browser refresh problem).

Another issue: motion settings cannot be changed from the web page ("save" with new settings just reverts to old setting). Manually editing /etc/motion/motion.conf does work, of course.
Many thanks for saving my sanity. I was having the same problems in 5.1.6 and when restarting in an SSH session it said couldn't open motion.conf, permission denied and then the /dev/video errors spewed down the screen.. Well found!
Confirm that motion settings aren't being changed from the web page in 5.1.6.
This is probably a consequence of changing raspimjpeg to www-data whereas before it ran as root. As raspimjpeg starts and stops motion then motion was running as root before but now runs as www-data so doesn't have same permissions as before.

I don't want to spend time on that as we hope to abandon motion soon with one built into raspimjpeg so the whole motion separate screen goes away and gets replaced by a new accordion on the main page.

This is what I am using for set up of internal version.
motion.jpg
motion.jpg (22.62 KiB) Viewed 2127 times

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RPi Cam Web Interface

Mon May 04, 2015 3:39 pm

@btidey: I really appreciate all the development you've done on this program. Is the new internal motion-detect version coming right away? The existing version from github is currently broken for anyone using motion-detection, but it is easily fixed with the one file permissions change I mentioned. I would think it would merit that fix?

My very limited experience with motion-vector algorithms is that they work differently than the old 'motion' program; eg. detect different conditions, and can be more susceptible to certain false-detect conditions. There may be some people who prefer to use the existing motion program, even if given the choice to use the newer one.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 6:22 pm

jbeale wrote:@btidey: I really appreciate all the development you've done on this program. Is the new internal motion-detect version coming right away? The existing version from github is currently broken for anyone using motion-detection, but it is easily fixed with the one file permissions change I mentioned. I would think it would merit that fix?

My very limited experience with motion-vector algorithms is that they work differently than the old 'motion' program; eg. detect different conditions, and can be more susceptible to certain false-detect conditions. There may be some people who prefer to use the existing motion program, even if given the choice to use the newer one.
I have added those group / permission changes into the repo. Thanks.

The inbuilt motion detection is working for me, but I think there are a few more steps before this can be regarded as a replacement.
In particular,
  • I get some camera errors when coming out of motion detection mode.
  • The default settings haven't been tuned
  • The mask image code hasn't been activated yet.
  • The detection is working at full frame rate (e.g. 25fps) unlike motion which is working on a much slower rate. Currently start and stop detection is based on frame counts so these need to be fairly high to get a longer interval. E.g. 50 frames for stop gives 2 seconds of 'stillness' to trigger a stop. Might change this to a time period like 'gap'.
  • The initial detect algorithm is fairly simple just to get things going. However, because it is working with motion vectors rather than with raw pixels, it has a good head start over regular 'motion' processing.
  • The nature of the vector data lends itself to more sophisticated processing. Quite a lot of the hard work has already been done by the video codec on the GPU, and the amount of vector data is relatively small so work can be done on this without blowing the CPU away.


I think the idea is to get it as good as current motion as quickly as possible. It would get messy to support both modes. Currently, the motion detect branch has stopped using external motion. However, we could revisit this if it looks like we can't get the equivalent.

0lly
Posts: 77
Joined: Sun Mar 02, 2014 5:07 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 7:20 pm

Zoom Preview (click on Preview) is not working in 5.1.6.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 8:19 pm

0lly wrote:Zoom Preview (click on Preview) is not working in 5.1.6.
Thanks
I broke that with a change I sync'd to the motion detect branch.

I'll check it out.

User avatar
jbeale
Posts: 3491
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RPi Cam Web Interface

Mon May 04, 2015 8:50 pm

btidey wrote:I have added those group / permission changes into the repo. Thanks.
(...) I think the idea is to get it as good as current motion as quickly as possible. It would get messy to support both modes. Currently, the motion detect branch has stopped using external motion. However, we could revisit this if it looks like we can't get the equivalent.
Thanks for the permission change update, so at least now there is a working version with 'motion' even if it doesn't get followup support after the motion-vector release. (Right now the install script seems to auto-update to latest; is there any mechanism to request installing a previous version?)

I understand it is a major pain to support two versions and I agree it's reasonable to abandon 'motion', if the replacement is functional; even better if a user could somehow choose at the 'install' step the old/unsupported/not-updated (but still working) 'motion' version.

I've currently got three systems running RPi Cam Web Interface with motion 24/7. If you'd like beta testing for motion-vector, let me know :-)

In the past I actually made my own flavor of motion with a very simple algorithm all in Python, with the picamera library. It mostly works but I decided I needed to do true "object detection" instead of per-pixel change detection to make it better, and that would be more complex. https://github.com/jbeale1/PiCam1

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Mon May 04, 2015 10:07 pm

jbeale wrote: Thanks for the permission change update, so at least now there is a working version with 'motion' even if it doesn't get followup support after the motion-vector release. (Right now the install script seems to auto-update to latest; is there any mechanism to request installing a previous version?)

I understand it is a major pain to support two versions and I agree it's reasonable to abandon 'motion', if the replacement is functional; even better if a user could somehow choose at the 'install' step the old/unsupported/not-updated (but still working) 'motion' version.

I've currently got three systems running RPi Cam Web Interface with motion 24/7. If you'd like beta testing for motion-vector, let me know :-)

In the past I actually made my own flavor of motion with a very simple algorithm all in Python, with the picamera library. It mostly works but I decided I needed to do true "object detection" instead of per-pixel change detection to make it better, and that would be more complex. https://github.com/jbeale1/PiCam1
git clone always get the latest version but one can git check out either by a specific version based on its hash or by date.
http://stackoverflow.com/questions/1225 ... ithub-repo I think one might need to comment out the pull in the installer to avoid getting the update.

The motion detect stuff is in a branch of the repository so that can be cloned instead of the master.

That would also be a way of supporting both during any transition, The installer could give alternate pull commands to get one or the other.

nthnm
Posts: 15
Joined: Wed Apr 01, 2015 9:35 pm

Re: RPi Cam Web Interface

Tue May 05, 2015 9:12 am

btidey wrote:This is probably a consequence of changing raspimjpeg to www-data whereas before it ran as root. As raspimjpeg starts and stops motion then motion was running as root before but now runs as www-data so doesn't have same permissions as before.

I don't want to spend time on that as we hope to abandon motion soon with one built into raspimjpeg so the whole motion separate screen goes away and gets replaced by a new accordion on the main page.

This is what I am using for set up of internal version.
motion.jpg
The motion vector preview is a really nice idea. If I understand correctly, it should make it much easier to tune the motion vector settings. I have been setting motion's "output motion" setting to do the equivalent, but obviously that isn't live, so this will be much better.

btidey
Posts: 1622
Joined: Sun Feb 17, 2013 6:51 pm

Re: RPi Cam Web Interface

Tue May 05, 2015 9:55 am

btidey wrote:
0lly wrote:Zoom Preview (click on Preview) is not working in 5.1.6.
Thanks
I broke that with a change I sync'd to the motion detect branch.

I'll check it out.
I've reverted that bit of the change that broke this so full screen should work again. The change was needed for motion vector preview so I'll fix it on that branch.

Return to “Camera board”