ZoneMinder Forums

Taking full advantage of various IP camera's capabilities, it would be great if ZM could create events for batches of frames uploaded to a ZoneMinderFTP server. For example:

-Under Add New Monitor, selecting source type of FTP displays a new tab to setup the cameras incoming login/event creation thresholds/filename & timestamp format from camera/ramdisk options/etc. Direct streaming and control options should still be available if the cam is supported, but not required for FTP.
-IPCAM records motion to its internal buffer, and uploads timestamped images to ZMFTPd
-ZMFTPd monitors its root directory and waits the allotted time for a new events images to finish uploading (ie waits 2-3 seconds after the last image to be sure it has the last frame for the current event)
-ZMFTPd immediately moves these files to their own event directory, renaming them to the expected format (00*-capture.jpg).
-ZMFTPd inserts the new event to the database, populates the interface

This would serve multiple purposes:
-Improves wireless support - latency is no longer a major issue.
-30 fps can be captured and transfered over a weak wireless connection if desired.
-Offloads motion/thermal detection to the individual cameras
-Saves wear and tear on the server, reducing CPU load - no decoding required!
-May provide better support for cameras which require ActiveX, but offer FTP transfer options.
-Some cameras allow you to configure different filenames and/or upload paths for various trigger types (ie motion/thermal), which gives a way to inform ZM of what caused the detection.
-Post-processing the images with ZM gives greater control through use of zones, but using the IP cameras built in features for the initial 'trigger' can also eliminate a lot of network overhead...

This may be dependent on the camera having a timestamp option. I could likely accomplish most of the above with a combination of software and some bash scripts, however this would benefit many people if included in an official ZM release. Unfortunately my perl skills are lacking...

Here's an FTP server written in perl that could possibly be implemented:
http://search.cpan.org/~rwmj/Net-FTPSer ... PServer.pm

Thoughts??

Regards,
.

There is indirect support for this already using the File monitor type. However the retrieval of the files is really outside the scope of ZM and subject to so many technical and preference variables that would add a lot of complication to ZM just to support a limited number of users/cameras.

For your circumstances it would be relatively simple for you to write a simple script using wget or curl and use double buffering to flip flop between images that ZM would read using the File monitor type. Then you can set it up with whatever login credentials and update intervals you want.

However this isn't exactly what you were suggested which seems to be to use a camera's own event detection mechanism. This is best done directly through the camera I think and someone posted only a few days ago how they had got this to work with ZM, to offload the motion detection to the cam but have the events created and stored in ZM.

Thanks for your reply,

I experimented with using the file monitor type to watch a file created by the camera via FTP, but it seems its limited to 1 FPS. CPU usage was also considerably higher (using nodetect). ZMC consumed 30% CPU when monitoring a single file (at 10 FPS), where as a 'remote' stream from the camera was only around 10% (with modetect).

If I end up writing a script to import the events from FTP to ZM i'll certainly post it here. I'll probably end up prototyping it in bash, and eventually rewrite it in perl as a learning experience I assume the post you were referring to is here:
http://www.zoneminder.com/forums/viewto ... xis+script

The problem with using this, in my case, is that it relies on TCP notifications and streaming directly from the camera. My camera only supports HTTP/email notifications. Furthermore, its wireless - I'm maxing out at around 6 FPS and latencies can vary drastically, so even if i'm using ZM to stream directly it drops frames from time to time. This problem could be eliminated by doing an active FTP transfer when the camera detects motion and/or thermal, at a full 30 FPS, with minimal network usage.

My Panasonic BL-C131A is currently setup to 'return' to watching my car through a window, but upon thermal events moves to record activity inside the house. This really exploits its PTZ features for covering everything I would be interested in monitoring, with 1 cam. It doesn't record the panning actions, only the real activity.

To test, I tried manually copying/renaming the FTP'd files into ZM's event directory, incrementing the directory name (event ID) by one. By the looks of it, I will also need to insert a row into the event table in the DB. Of course this is not the best way to do things (customizing zmtrigger.pl is probably better), but I only want to monitor this 1 IP PTZ cam for now.

Can you please confirm that all this custom/hacked together prototype script would need to do is create the event folder with the properly named ***-capture.jpg images, and enter a record into the events table in the database? If so it really shouldn't take much effort. Not sure if i'm overlooking something else...

If I manage to get this working well I'll look into writing a perl application which does what I described above. ZM is awesome software, thanks for keeping it open source!!!

Regards,
.

Thanks for your response and kind words. You are correct in your identification of the post I was referring to.

I think you have a good idea and I agree that writiing a custom script is probably the way to go. A new camera type would imply changes to the capture daemon and that is not really where complex file manipulations and transfer etc should go so I think you are going along the right lines.

To create an event you would need to
1) Enter a row into the Events table
2) Enter a row for each frame into the Frames table. This includes timing and other frame specific information.
3) Create a directory for each event using the id from (1) above. Note that if you are planning to make your script available for general use you should probably support the newer deep storage file system as well as the old events/<monitorid>/<eventid> structure that you have mentioned.
4) Create a capture image file numbered by frame id for each frame and (optionally) an analysis image file if there is any highlighting etc that you have added (which is unlikely in your case from what I understand).

I think that's about it.