ZoneMinder Forums

This forum is for discussion of the new architecture for ZM version 2 and beyond. To limit spam and off-topic posts participation is limited to members of the Contributors group but I am happy to add anyone who asks to that group.

Am very much liking this concept. With the difficulties in dependencies seemingly becoming more apparent and making zm harder to build, a monolithic approach does have significant merit.

While perl's strength is very much being able to pull in modules left right and centre, it can make it more difficult to support going forwards if they aren't available in the distro. Cpan is good but sometimes non-user friendly. Can these modules, if required, be bundled in the source?

What about plugins, is there scope for something like apache2's conf.d where you can drop user or official plugins to support new formats, new behaviors, new algorithms, x10 or other external supports?

I'm a firm believer in working harder to make it easier for the end user, and unless zm can be reliably trivial to install as "apt-get install zoneminder" then people will try it, get frustrated if it doesn't work within five minutes, and try something else. (Not that there is much else that does what zm does!) The shared memory issue is a big one and good to see progress to avoid it entirely - that's the sort of thing. Also a better way to automatically add ip cameras based on makes - a user maintained extension to the presets.

Easier log reporting - being able to click on the ui to show logs for a specific monitor - would help people diagnose more quickly.

I love zoneminder, I love that it's free and does a fantastic job. Our charity would really struggle to pay the licence fees of any of the commercial software that gives similar functionality.

ZM captures image.
Passes it to a plugin directory and all plugins there called. (Or database reference so that you select which plugins are required for each monitor)
Plugin then parses the image (or stack of images if an event, or passed a path to a set of images)
Plugin does its thing, matches to external database etc.
Plugin then exits, and feeds information back to zoneminder to be stored on its db alongside the event info (ie, Employee name/id, Number plate etc)

Plugins could also help control whether an event is stored, whether it even triggers at all (could the motion detection in zm actually be a plugin?)

Addons in other areas could also parse additional streams (one plugin for jpg, one for mjpeg, one for mpeg4, rtsp, whatever), automatic behavior (converting all archived events to video and exporting off system), disk filters etc.

Flasheart wrote:Easier log reporting - being able to click on the ui to show logs for a specific monitor - would help people diagnose more quickly.

Have you had a look at 1.25.0? There's still the odd wrinkle I'm ironing out but hopefully that has addressed the logging issues.

Just an idea,
About diagnosing problems, I've done a little test and used the Annotate function to display errors (and not just report to the syslog), It actually worked well with the exception that the 2nd line was cut.

Flasheart wrote:From a discussion with mastertheknife, MDesade and myself on irc.

It would be good if zm2 allowed external plugins to parse info.

Say, facial recognition, ANPR.

Something like:

ZM captures image.
Passes it to a plugin directory and all plugins there called. (Or database reference so that you select which plugins are required for each monitor)
Plugin then parses the image (or stack of images if an event, or passed a path to a set of images)
Plugin does its thing, matches to external database etc.
Plugin then exits, and feeds information back to zoneminder to be stored on its db alongside the event info (ie, Employee name/id, Number plate etc)

Plugins could also help control whether an event is stored, whether it even triggers at all (could the motion detection in zm actually be a plugin?)

Addons in other areas could also parse additional streams (one plugin for jpg, one for mjpeg, one for mpeg4, rtsp, whatever), automatic behavior (converting all archived events to video and exporting off system), disk filters etc.

A lot of possibilities and things we can't think of yet!

Yes, this should be possible. The whole concept of ZM2 is of providers and consumers. So you can have a video provider for a local camera or a network camera which can pass frames to a streaming consumer (for viewing) or to a motion detection engine (consumer). The components can be both providers and consumers so a video provider can pass frames to an ANPR engine, which then passes it to a facial recognition engine which then passes it to a streaming or file writing consumer. This is an example of serial consumers but they can also run in parallel.

This is a much more flexible architecture but there will probably be some penalties in performance as the scope for optimisations may be less. Providing processing blocks as plugins would be great but can be a bit fiddly in binary applications and would not necessarily make life simpler, especially if people mix up things from different versions. At the moment the block interfaces are common so plugins could be used if a good framework for them was created. I do have a more or less functional proof of concept for all this so can let people have a play once I have figured out a knotty little issue with passing multiple ROIs from zones to alarms.

Flasheart wrote:Easier log reporting - being able to click on the ui to show logs for a specific monitor - would help people diagnose more quickly.

Have you had a look at 1.25.0? There's still the odd wrinkle I'm ironing out but hopefully that has addressed the logging issues.

Just an idea,
About diagnosing problems, I've done a little test and used the Annotate function to display errors (and not just report to the syslog), It actually worked well with the exception that the 2nd line was cut.

Yes, it was written just to present some very specific short messages and not general text. The same message will be presented in the 1.25.0 log viewer and will be highlighted in red, along with any other errors or warnings all in the one place.

Flasheart wrote:Easier log reporting - being able to click on the ui to show logs for a specific monitor - would help people diagnose more quickly.

Have you had a look at 1.25.0? There's still the odd wrinkle I'm ironing out but hopefully that has addressed the logging issues.

Alas no, sorry, but great to hear you've already addressed it!

Another random thought - can zm2 detect a stream in a more user-friendly way for ip cams? Not guess a path, that could take forever! (Although... a few popular paths could be tried I guess), but if given a path could it make assumptions about what type (jpg, mjpg, mpeg), whether colour or B&W (note: zm doesn't seem to have any problems when set to colour for cams that revert to B&W in low light), and guess x & y, perhaps on that camera's daemon start?

x&y seems to be one area that new users get wrong occasionally.

Yes, this should be possible. The whole concept of ZM2 is of providers and consumers. So you can have a video provider for a local camera or a network camera which can pass frames to a streaming consumer (for viewing) or to a motion detection engine (consumer). The components can be both providers and consumers so a video provider can pass frames to an ANPR engine, which then passes it to a facial recognition engine which then passes it to a streaming or file writing consumer. This is an example of serial consumers but they can also run in parallel.

I like the new logging page. Its really nice especially for later debugging issues.

Just though I would repeat a post i saw in feature request. We should also be logging logins and attempted logins to the system at a minimum. (maybe later changes made to ZM: Cam Settings, User Accounts, etc...)
As every other system seams to do it for user accountability: Worpress, Vbulleten etc...

Also a nagging thing chrome and opera should be added to the mjpeg supported list.