Motion Rearchitecture Discussion

Introduction

The issue has been raised about rearchitecturing Motion. As Kenneth points out in the RoadMap, this is not very urgent and more of a 4.0 thing. However, we should start thinking about it already now.

These are some issues that I think need to be addressed (in no particular order):

• Complex code. The code is unnecessarily complex and can be very confusing to a newcomer. It is easy to overlook something when you write a patch, which may lead to severe deterioration of the code.
• Non-flexible architecture. As it is now, it's not very easy to add new input sources, new output formats or to modify motion detection. For example, what would be needed to support raw pwc streams? Or some camera with a yet unsupported image format?
• Bloated configuration handling. The configuration file now has tons of options, and the corresponding structure in the code is massive. The issue is complicated further by the additional thread configuration files and command-line options. I think this can be confusing from both user and developer perspectives.
• Not entirely FreeBSD-friendly setup. To me it seems awkward to have to copy the *.freebsd files and run autoconf before you can build Motion for FreeBSD. There should be a solution that is more transparent to the users.
• And so on. Feel free to add the ones I've missed

Solutions

These are just some possible solutions:

• Dynamically loaded modules. This is a really cool idea that Angel has experience in. By allowing Motion to load modules on-the-fly, we would achieve great flexibility when it comes to adding new input sources, output formats and so on.
• Pipes&filters architecture. I think a (somewhat relaxed) pipes&filters architecture would fit Motion nicely. For example, you could create (via the configuration file) something like: {webcam input} -> {auto-adjust light} -> {rotate} -> {detect motion} -> {store in db} -> {output mpeg4}. To input from a network camera, you would just replace the first filter with another one.
• OS abstraction. To increase portability, we could introduce a layer to abstract away OS-specific stuff. Perhaps it would be possible to port Motion to other interesting platforms.
• Rewrite in C++. Angel quickly dismissed my idea to change language, arguing about loss in performance. While I don't agree there must be a performance penalty, I do admit now that the footprint would certainly be negatively affected. We don't want to have the libstdc++ weight on us. And we don't want to be Zone Minder.

I think the ultimate design goals should be flexbility, tailorability and ease-of-use.

-- PerJonsson - 30 Sep 2004

• Rewrite in C++. I think also this is really not a goo idea: I was able to run Motion on a Floppy which contains the Linux kernel and a minimal file system. Using uClibc it is possible to have a very small binary (500k, statically linked!!!). Migrating to C++ will cause the binary really bigger (I guess 2MB statically linked). On desktop this is not a problem but on embedded systems... An other point is the portability, the C library is old, so robust, if you use an other compiler you can expect that the code can compile without big issues. With C++ you can have a lot of trouble due to some library bugs (specially when people use STL).

-- SebastienFricker - 23 Jan 2005

Proposals

Motion split and redesign

a) Motion is a nice app which does 3 things:

1. connects to cameras
2. does processing of image sequences (motion detection)
3. does record and/or triggers alarm events

b) We could divide this parts into 3 different projects:

1. a powerful camera connection library
2. a specialized video sequence analysis component (the soul of motion)
3. a event triggered recording and alarming component

c) The 3 advantages of this approach would be:

1. more clean structure
2. more robust internal data types (a good API will become necessary)
3. other projects could use just the piece of motion they need.

About point c.3: http://pandora.dii.unisi.it/cgi-bin/twiki/view/HuMoRweb/WebHome MotionHuMoR could benefit from the great motion quality in getting images and handling events. Motion could use http://pandora.dii.unisi.it/cgi-bin/twiki/view/HuMoRweb/WebHome MotionHuMoR ability do detect moving objects in complex situations.

Adopting this subdivision the b.1 & b.3 components can be implemented in slow easy to manage languages (python, ruby, php...) while the b.2 can be coded in C or even assembly and just provide a nice interface for the outer world.

About plugins. Using this approach one can develop b.2 with plugins in mind:

1. providing easy modification of the motion detection core algorithms without messing the camera and alarm code
2. providing an interface to customize the behaviour of just just the motion detection algorithm
3. allowing the developes to prototype theyr own algorithms using scripting languages

-- VincenzoDiMassa - 20 Feb 2005

Related Topics

• GSTMotionDiscussion

---

Comments and Discussion

Comments, anyone?

---

Why not based all the motion implementation in GStreamer... we don't need to reinvent the wheel.

-- AntonioBeamud - 09 Feb 2005

---

It might be worth having a look at camsource for ideas. http://camsource.sourceforge.net/ "It features a modularized and multithreaded design to offer a large amount of flexibility. A server plugin runs in its own thread, which makes it possible to use the same grabbed frame for several purposes at the same time. There are also filter plugins, which can be daisychained to create useful and no-so-useful effects in images." For instance, you can stream a thumbnail image, while doing timelapse with a medium image and running its own motion detection algorithm on a large image.

-- IanMcConnell - 22 Feb 2005

---

Camsource is a bit different from what I have in mind: it is a system to get images out of a V4L camera and to do various thigns with those images. What I would like to have is a library able to get images from vaious kinds of cameras and transform them only to make them conformat to a defined API or data format. What I have in mind is a sort of camera abstraction layer able to completely hide the low level details of cameras to the calling program. After images (streams of them) are put into a standard format we can:

1. save that stream for later use
2. do whatever we want to that stream (online)
   1. motion detection
   2. image enhancement
   3. format conversion
   4. flip, rotate ...

I hope this clarifies what I'm talking about.

-- VincenzoDiMassa - 22 Feb 2005

---

Vince. Interesting thoughts.

Actually the way the kernel driver development is going they are pushing more into "userland" so in the long run we have no option. The virtual camera is something the OSS community has to do.

I am not a hard core programmer - I am a manager - also by profession. This is why since I took over the project the development of Motion the actual coding has been done by a larger team and my effort has been mainly to setup and maintain the environment like this Twiki, maintain a roadmap and filter/change the ideas that arrive so that the basic idea of Motion is maintained.

So inputs like your are most welcome.

There are some thoughts that everyone should consider. Motion is a program that tries to follow these basic principles.

• Motion is a Motion detection program. It can pick up a video signal, detect motion, and save picture and films.
• Motion is highly flexible. It can trigger all sorts of external events.
• Motion is a daemon. Not a bloated GUI program. It runs in the background and enables you to use the computer for other things including normal desktop.
• Motion has a small footprint bith with respect to memory and CPU cycles. One can easily let Motion run 10 cameras on one machine. Motion has reached the limit where people experience that framerates slows down. A lot of code optimization has been made recently to speed up Motion. This is why things like face recognision and fancy GUIs does not belong in Motion.
• Motion (and any softwate IMHO) should be easy to use by a newbie. You should not have to be a programmer to use it.
  • Motion is NOT easy to use today. The reason why it is popular anyway is because it is so well documented. But the newbie questions we get shows that there is still a lot to improve.
  • XMLRPC interface is being replaced by http in 3.2 exactly to address the ease of use aspect. XMLRPC is for programmers. http is for anyone.
  • Options in the config file have been renamed in small evolutionary steps to make it easier to understand. New features added that required new options triggered days of throughts just to define the name. JoergWeber and I took a long time to find out how to control the new smart mask feature as an example. We ended up with ONE simple option and quite a nice feature. We still have a long way to go in getting Motion more newbie friendly when it comes to config files.
  • Command line options will be removed now except for 3-5 that are related to location of config file, daemon mode and setup mode.
  • Motion is ONE executable AND a config file. You need nothing else. Well this is not entirely true. You need libraries like ffmpeg. Until recently you needed cURL. This is now eliminated. The library dependencies, the thread config files and camera drivers are the issues that causes most problems for people. The trend in latest Motion development has been to simplify the dependencies. A lot of effort has been put into making the configure script fully automatic. Only a small fraction of users are programmer and only few understand what a shared library and a header file is. Most are scared of installing a simple patch.
  • There is not something wrong with people. There may be an occational extraordinary slow newbie. Even they get threated well on what we all call "the friendliest mailing list on the Internet. There is something wrong with the program when newbies have problems.

So now that the basic idea has been outlined - what about the rearchitecture ideas? It that impossible? Not at all.

We can split up Motion functions but we have to be very careful in how we do it. We can turn Motion into a complete nightmare if we do it wrong. We can also turn it into something quite brilliant.

It is essential that new architecture idea go hand in hand with how to simplify the users interface when implementing it. And simplified users interface is not a KDE or Gnome GUI integrated into the Motion executable. I also want to maintain small footprint and ability to install and control Motion from command line and web browser. If people want to make a GUI it will be an independent program that remote controls Motion and/or hack the config files. Motion is a daemon with small footprint.

I would really like to see Motion having a flexible plugin system both on the input (virtual camera) with a nice API that encourage programmers to develop nice small feature that are easy to add (copy file and add one line in config file) and on the output so you can plug all sorts of processing add-ons.

-- KennethLavrsen - 25 Feb 2005

---

Kenneth, I'm completely with you when you say motion is a fast, light motion detection software. I also like a lot the idea of the "remote control" and plugin system. My proposal has to be read like: "motion should be kept simple and should not care of setting up image sources". There should be an external, nice (for the newby and the programmer) camera library to ask images to. When I say external I mean motion should be one executable, the library should be shared even if provided by motion itself. That library should be distributed together with motion, and current motion config file options should be all that is needed to get images out of that library. About the config file I find it would be easy and very usefull to give the newby a nice py/wx/qt/gtk/... config file setup application: the freeform of config files is not newby friendly, while the description:field structure of a sutup gui should be newby welcome. But this is not in my TODO.

-- VincenzoDiMassa - 25 Feb 2005

---

Decision from Kenneth Lavrsen

The discussion: should Motion be a plugin for Gstreamer, should Motion be able to use xvid, should Motion be able to connect to camera Y with proprietary interface etc.

I have often been critical like above or said plain NO WAY. And with for example Gstreamer INSTEAD of current interface my answer is most likely "go away".

But it does not have to be "go away" and "No" and "I do not understand so I do not approve".

The answer is: Motion must be changed to have a generic and general purpose plugin architecture.

The plugin architecture must be implemented so the current good, stable, well working, and dammed fast direct access to camera devices and netcams and ffmpeg libs are DEFAULT plugins shipped with Motion and working so the normal user hardly will notice the difference. There may be a few new plugin related config options with a note saying "don't change this unless....blabla".

And this new plugin architecture must have a well defined API which we must try to get as complete as possible and try to keep as stable and backward compatible as possible after a period of time.

The end result should be that people - who want to write code that implements what people like BillBrack and VincenzoDiMassa has been pushing me to do for a long time - can do this as their hearts desire without asking for permission from the "Boss".

And my hope is to see other plugins in the future that has nothing to do with Gstreamer. Movie outputs without ffmpeg. All sorts of funny new ideas.

Once we implement this I will create a new "plugin" area on this Motion Twiki where people can upload their plugins. And from where people can download them and install them.

To put all the new ideas into words before code the PluginArchitectureDiscussion topic has been created for this. Those of you that want to implement a Gstreamer plugin should be very active in pushing this plugin API so that their vision can be implemented as you want it and so it can relatively easily implemeted. You will most likely be the first to use the plugin API.

-- KennethLavrsen - 27 Aug 2005

---