POLL: Motion vs Motionplus

[Mr-Dave]

Due to user feedback, the existing Motion application has been held static over the previous years. While this has resulted in a consistent user interaction with the application, it has also resulted in the application not being as useful as it could be.

To address this user feedback and the need for use of new tools, the Motionplus application was created and forked off of Motion as of version 4.2. Motionplus has now effectively re-written almost all of the Motion code but in the process has also removed some functionality. The maintainer believes that the removed functionality was rarely used and as such needed to be retired. e.g. Multiple input v4l2 cards(round robin), exotic motion tracking, unmaintainable assembler code, use without the ffmpeg software, etc.

While this has occurred, the outside environment regarding security camera software has also changed dramatically. Virtually all new security cameras include some sort of AI/ML or Human detection process which the existing Motion code can not implement. Only the Motionplus code base could implement anything similar to what is being provided by the stock software of the cameras.

Now we get to the question of this poll. Should the Motionplus code be migrated into Motion. This is set up as a yes/no and below I've tried to point out some of the implications of each choice.

No:
This is essentially the status quo. The existing Motion code does not get any enhancements or revisions. Configuration parameters don't change and it works as it has for the previous years. Motionplus would be the application for implementing AI/ML human detection, direct libcamera functionality, etc. The vast majority of users would continue to only see the Motion application code since that is what is distributed via package managers of Debian, RPM, etc.

Yes:
This would mean that the code would transition into what is currently in Motionplus. The 4.6 branch would be maintained as the "old" unchanged version and only revised to allow it to compile. (i.e. If a user wants some of the retired functionalities, they would have to build it themselves from the 4.6 branch.) The Motion code would then be the application for enhancements, code revisions, different parameters/names, methods, etc, etc. The majority of the users would get the revised methods since they would be distributed via the package managers. The following is a list(not complete) of things that are lost or gained as part of Motionplus.

1. Using Motion without ffmpeg is currently possible. Motionplus requires ffmpeg.
2. Motion allows for the use of only a single config file. (motion.conf). Motionplus requires a camera.conf file.
3. MYSQL support was removed from Motionplus in favor of MariaDB.
4. Assembler code was removed from Motionplus. (possible lower performance)
5. Round-Robin was removed from Motionplus (i.e. Support for video cards with multiple inputs)
6. Detection was increased from 3FPS to every frame in Motionplus (possible lower performance)
7. Multiple ports for streams was removed from Motionplus(could add back if significant interest).
8. Webcontrol changed to "post" from "get" methods.
9. BSD Brooktree devices not supported in Motionplus.
10. Pi camera functionality allowing all changes to camera parameters (libcamera) in Motionplus.
11. OpenCV processing / detection supported in Motionplus.
12. Sound frequency detection supported in Motionplus.
13. Add/Delete cameras via webcontrol in Motionplus.
14. Single consolidated image streamed of all connected cameras provided in Motionplus.
15. Mpeg transport streams are provided via Motionplus.
16. Functional changing of parameters via webcontrol in Motionplus (Motion does not consistently implement configuration changes via webcontrol).
17. etc

[buteomont]

Does it have to be all or none? For example, controlling Motion via simple GET URLs is much easier and simpler than POSTs.

[dynamohum]

I'm not entirely familiar with controlling via GET or POST but isn't option 8 saying that motionplus would be moving to GETs from POSTs?

Personally I like what is being proposed. As another commenter says, camera surveillance software has changed a lot since Motion first came along and it's important to stay up to date with new camera technologies.

[Mr-Dave]

Motionplus uses POST and a recent discussion question provides an illustration of the differences. (This answer made it into the documentation examples but has not yet been published on the home page)

[dynamohum]

Oh OK thanks for the clarification Mr-Dave.

[Mr-Dave]

Yes. You should view this as a "all" vs "none".

[AntiSol]

Couldn't something like a "best of both worlds" situation be achieved relatively easily, by simply creating a distinct motionplus package for the distros? Then:

• users of the motion features unavailable in motionplus don't lose anything
• motion stays backwards-compatible and doesn't break anything for anybody (because it stays the same)
• wikis and tutorials can be updated to encourage users to try motionplus (also the naming implies that motionplus is wnhanced in some way, should encourage its selection over motion)
• you could get some metrics of install numbers of motion vs motionplus from distros, allowing you to make more informed decisions as to what users are using, perhaps revisiting this question once most users have switched to motionplus

There would be some work in creating a motionplus package for the various distros, but once that is automated and integrated into your release process it should be easily sustainable long-term, requiring little maintenance work, and seems to address most of the pros/cons listed, keeping all of the pros and avoiding most of the cons.

[yochanon]

Some distros don't need that fancy 'packaging'. For instance, Slackware. We build ours from scratch using the source package (I've not tried motionplus yet, so not sure how easy/difficult this particular app can be for Slackware users to build). I do want to use motionplus though, as security cameras are too important to let lapse and lean on old code, thus I hope motionplus gets to be the winner here.

[tosiara]

I personally still use motion as it is stable and mature and can be tuned to use less resources on ARM.
However I appreciate and support efforts of building modern motionplus as there was demand for features that it introduced.
Voted for keeping separate development, because in my opinion it is more efficient and will keep old motion stable, while introducing new features more easily. But I'm always open to repeat the poll in a year or two and maybe port back some small features to motion.

[MrDimly]

If resources allow, it makes sense to keep both versions separate. Motion only receives important fixes and very rarely implements changes from the MotionPlus branch. This will increase the reliability of Motion - for example, version 4.6.2 stopped working with one RTSP camera, but works with another. Until I figured out the reasons, I rolled back to 4.3.2

[RVTim]

I did vote to merge, however, I agree with MrDimly. If resources allow, it would be nice if they were separate. My motion setup has many customizations and the last thing I need is to spend more time fixing things that unexpectedly break. I don't want to hamper development but I would prefer to be able to stay on a stable version for extended periods. I can see that over winter I may take time to install motionplus and see if I could get it to do everything I'm doing today, and if so, I'd migrate, but I really don't need extra work in the summer and fall.

[matijag]

I am very much of two minds about this. From a user standpoint, getting updates to the packages that come with my distro is more comfortable, I don't have to do much. From a standpoint of looking for documentation/help, searching for "motion" bring a lot of irrelevant results, searching for "motionplus" would probably help with that.

I would really like OpenCV integration (particularly if I can turn it on per-camera, and if it has separate actions associated with detecting stuff of interest.

As for the "possible lower performance" I would really like to know "how much lower performance" before I decide. But I imagine removing assembly code did not have much impact on the Pi platforms, since the assembler for that would be completely different.

I love this project, thank you for working on it.

[Mr-Dave]

Thanks everyone for your feedback so far.

I will be keeping this poll open indefinitely to understand the perspective of the community and you're invited to revise your vote either way if your mind changes. Just make sure to consider that you are also essentially voting for what you think 1,000s and 1000s of others would want.

In the interim with these results, I think that that status quo will remain. Absolutely no enhancements to Motion. Motionplus will be the application for further development.

MrDave

[AntiSol]

Thank you @Mr-Dave for involving the community in the decision making process, and for erring on the side of caution given the response, and of course for all your work on the software we love.

[xj25vm]

How about renaming Motionplus to Motion 5.0 - and the old 4.6 to just get minimal maintenance into 4.6.1, 4.6.2 and so on and so forth? Many large software projects have gone through a major re-write - and this usually becomes the next major version number - with the old one still kept available for those who prefer/need the old functionality. For me, the option to perform secondary detection through OpenCV, even once a second - to confirm the footage is worth keeping, but keep processing to a minimum - possibly with some sort of ability to use Google Coral boards, would be a massive plus. As it stands, motion detection and motion notifications are only reliable in small, relatively well lit spaces. For larger spaces/rooms or outdoors with vegetation and wind and rain, even with all the tweaks and configurations available, motion detection has far too many false positives. Plus the fact that with classic Motion there is no way to distinguish between animals and humans, for example.