ZM2 Architecture Discussion

Update: See http://ozone.network for more recent updates

This page is an initial discussion of the proposed new architecture for ZoneMinder version 2 (ZM2).

The ZM2 architecture will not be purely targetted at providing specific ZM binaries but will form the basis of a framework allowing other more specialised applications to be created.

The key components of the ZoneMinder Framework (ZMFW) can be summarised as follows

Frame

A frame is a piece of information that can be passed around the framework. This may represent video, audio or any other type of information. At it's simplest it contains nothing other than an id, a timestamp and a block of data. Specific frame types can include additional information, e.g. a video frame would include dimensions and a video format, an audio frame would include a duration, format and possibly sample rate etc.

Provider

A provider is simply an entity that can 'provide' other system components with frames. Examples might be analog camera video providers, or GPIO port status providers.

Consumer

A consumer is an entity that expects to receive frames from a provider. A local file consumer might receive video frames from a video provider and write them to local file storage.

Some key points about providers and consumers.

1. In order to receive frames consumers register with a provider (or a provider can register with a consumer).
2. Once a consumer has registered the provider will distribute frames to a consumer. In the general case this is unconditional but it can be made conditional on certain conditions.
3. A consumer has a frame queue allowing a number of frames to be lined up for processing.
4. A provider can distribute frames to many consumers.
5. A consumer can receive frames from many providers, though the normal case would tend towards only one.
6. A frame contains a reference to the provider from which it originated.
7. Providers and consumers are generally represented by threads and so run autonomously.
8. The ZMFW defines only a very limited interface and set of functionality. Specific providers and consumers need to extend this to suit their own specific needs.
9. Combined providers and consumers are supported. So an ZMFW object can both consume frames from one provider and thence distribute them to other consumers. This allows sequences of providers and consumers to form chains or even more complex structures such as mesh types. Owing to the conditional aspects of providing and consuming frames may take a variety of paths between entities.
10. As frames are passed around, they retain a history of their passage and record which providers they have traversed. Consumers may alter the data contained within a frame, but if they do so, the frame accepts new data but also maintains the original form. This allows consumers to examine or process both unaltered and processed data if both are available.

These simple rules allow some quite complex architectures to be created. For example the zmc process in the current architecture could be represented by the following ZMFW structure

 LocalCameraInput(P) -> MappedMemoryOutput(C)

where (P) represents a provider and (C) is a consumer. Obviously, the LocalCameraInput could alternately be a RemoteCameraInput etc. Likewise the current zma would end up being something like,

 MappedMemoryInput(P) -> SignalChecker(PC) -> MotionDetector(PC) -> EventHandler(C)

and the streams would be

 MappedMemoryInput(P) -> H264Streaming(C)

and so. In fact all those elements could now be in a single monolithic process if required, or a simple relay process could be formed of a capture input and a streaming output and so on.

The intention of the ZMFW is twofold. The first, and principal, reasons is to allow ZM components to be constructed in a more modular fashion, which also would allow additional entities to be added in from thrid parties using a defined API. So specialised I/O components can be built in, or ANPR type functionality without massively affecting the rest of the system. The second reason is to allow new components and even newapplications to arise from the framework to perform specific, perhaps currently unthought of, tasks outside the scope of the existing system.

This is just an initial brain dump. I will shortly be opening up a new forum for interested parties where anyone will be invited to contribute to discussions about the ZMFW and make suggestions and ultimately contribute to the generation of code.