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.

[Mr-Dave]

Reviving this poll.

Based upon the latest results and looking at what alternative software provides, I am now getting more inclined to migrate Motionplus into Motion and call it version 5.0. Those that want the old functionality would need to remain on the 4.7 branch.

[andrewfrongello]

Any ideas when this will be taking place? Should we be moving to motionplus beforehand?

[Mr-Dave]

It happened yesterday. The master branch of Motion now reflects the code of Motionplus. Development will proceed with the master branch and the Motionplus repo will be changed to a public archive very soon. The builddeb scripts will also be updated soon.

The one caveat is that an official release 5.0 will be probably be a while in coming. This will allow time for users to submit enhancement requests for consideration or implementation.

[andrewfrongello]

Thank you Mr. Dave. What is the recommended way to update to motionplus in the meantime? Or better to wait for the updated motion install/build guide?

[Mr-Dave]

It depends upon your needs. As of today, the code is the same between the Motion master branch and the Motionplus branch so you can use the createdeb scripts for that if you want or just wait until scripts/guide is updated.

[AntiSol]

What is the advantage of merging motionplus into motion?

I would expect that the majority of motion users aren't aware of and therefore haven't responded to the poll. Those people will be used to installing a package named 'motion' on their system that has a certain set of features.

These people will expect to be able to upgrade that package to a newer version and will generally expect that version to retain existing features.

For these people, when they upgrade and the newer version lacks features the old version had, this will (rightly imo) be considered "breakage". People will file bugs saying "motion lacks feature X that it used to have". There will be a support burden.

I refer you back to my previous comment where I advocate for simply packaging them separately and putting motion into a maintenance mode or deprecated state.

This way:

• people using motion as a distro package can keep using it without seeing features go away
• people who do this will eventually notice that the motion package isn't being updated, and maybe switch over to motionplus (expecially if you put a 'motion is in maintenance mode, you should try motionplus' message into motion's output)
• people who want motionplus but not motion can have it
• you don't need to keep maintaining motion

What do you and/or the community get out of merging motionplus into motion that justifies breaking things for people? Why can't it be a separate package and the main motion package be unmaintained?

[Mr-Dave]

Thanks for sharing.

[AntiSol]

@Mr-Dave I did a bit of re-reading, and a "find on thie page", and the phrase "You should" only appears in my messages once, as an example message motion could spit out saying "you should try motionplus".

In fact the first time the phrase "you should" appears in the discussion is........perhaps a little ironic:

So I'd just like to disagree a little more strongly with your assertion that my messages had a "you should" tone. If you think they did, please provide examples in the form of quotes and I'll be happy to take your feedback on board.

Also, I wanted to expand a bit more on why it's inappropriate for you to use comments I made after being ignored as examples of inappropriate tone: you claimed that you didn't bother to respond due to my tone, but things I said after you had already failed to respond cannot possibly be reasons why you didn't respond, due to the way causality works ;)

[Mr-Dave]

Sigh...Please go away and don't post here anymore or use the software.

[AntiSol]

...so, just to confirm, you have no response to any of my points or questions, and no interest in what the facts of the matter are, or what was actually said, or whether your actions are justified or not? The only thing that's important here is how butt-hurt you felt based on somebody having the audacity to ask you perfectly valid questions, right?

Got it. I'll formally announce my fork shortly.

[xj25vm]

@AntiSol although you have raised some valid points, please keep in mind that small open source projects like these are mostly the unpaid, unrewarded effort of one main developer - sometimes over many, many years. Although the developer might seek opinions or input from others sometimes, it is ultimately their project and they have the final say. It is not really a democracy or governance by committee. To put lots of time and effort into a project just to be rewarded with long convoluted arguments on GitHub can't be satisfying - and not everyone has the time or enjoys long winded arguments. You can fork, of course, if you choose to - that is how open source works - and hopefully that will result in more useful features and functionality for everyone to enjoy and use.

[xj25vm]

Another middle ground option could be to add the new major version number to the package name. A number of other projects have done this - to signal a major change of architecture. For example there is an iPerf and iPerf3 - and they are packaged side by side by some repositories - with iPerf3 being clearly a separate package, which is not expected to be fully compatible with the original iPerf - and the original iPerf being slowly phased out. Maybe something like motion5 - with actual versions starting from 5.0.1, 5.0.2 and so on. Then distributions could easily package motion and motion5 side by side - and it would be a clear signal that one is not the natural, seamless continuation of the other, and there has been a major change in architecture. Of course this would imply that the versioning scheme might have to continue for a long time in the format of 5.x.x and can't just move to 6.x.x, for example. Just an idea.

[leanne63]

I know you have a long discussion on this already, @Mr-Dave . I also know that MotionPlus has already been archived. I also am a developer and understand there are many intricacies and much time involved with creating and maintaining software, including the additional tasks of creating and maintaining separate distros for a package.

Having said that, I come to you as a newbie Pi user who's been trying to determine which package to use to set up a security camera - and I have to say that I agree with @AntiSol 's original sentiment.

There are so many camera-related packages out there. Most of the documentation I have found on how to set up a camera uses Motion, MotionEye, or MotionEye OS. A number of instruction sets have said the MotionEye/OS packages are no longer maintained, so they've used Motion as their basis. I came to the Motion GitHub seeking to determine whether it would work for my needs - only to find this MotionPlus package as well. AAAAHHHH!!!! Which do I choose??? I've little experience building my own Linux-based packages from source, so I'd prefer to use Motion because there's a distro. I can, with some effort, figure out how to do the build with adequate (read beginner) instructions, and it seems that MotionPlus is a more modern package. What to do???

After a couple of months of indecision, I finally decided to try to learn/perform the build process for MotionPlus, and use Motion if I couldn't figure it out. I return to the MotionPlus repo to see if I can find instructions - only to learn it's been archived! Wha???

Again, I've read this discussion through thoroughly, and I totally understand your desire to maintain only one package. But given the research I've done and the difficulties I've encountered trying to figure this all out myself, I strongly request that you return Motion to its former version, archive that one, leaving its distro in place (noting in the docs that this is no longer maintained - period!), and make MotionPlus its own, individual package, with its own individual distro - that is maintained.

This would ensure that non-GitHub users, who have no knowledge of installing software beyond a distro, can still follow the many, many instruction sets out there that use Motion as the go-to package. They can continue using the existing Motion until such time as it just won't work anymore.

Just as many non-developers don't understand the work and knowledge it takes to maintain a package, many developers don't understand the level of frustration for beginners who don't have a clue how to do something without beginner instructions and distros to hold their hand.