PI camera Support

[Mr-Dave]

Add functionality to support the PI camera.

[jogu]

I had a go at merging https://github.com/dozencrows/motion/tree/mmal-test (which is the very popular fork of motion that supports the raspberry pi camera) on my master, the result is at https://github.com/jogu/motion/tree/merge-mmal

I literally just managed to get it compiling (not even tried running it yet), it'd need a good cleanup, thorough test, etc. I'm not sure if there are things in that tree that may just never be suitable for merging into the main branch.

[tosiara]

Let's create mmal experimental branch. Hopefully someone can contribute and backport changes form @dozencrows repo into the new branch

[Mr-Dave]

Looks like @jogu has the branch underway already. I'd agree with his initial assessment that the branch needs a good cleanup. There was a lot of noise in there when I looked last night. Joseph, do you have a PI cam for testing?

[jogu]

I do, although currently only the older one (they recently released a higher resolution one, 2.1 MP vs the older 1.3 MP). I've not had a chance to actually try running the merged version yet.

[Mr-Dave]

Great. Even if it is older, that helps a lot. I do not have a PI cam so I'm relying upon those that do to assist in the development and testing. Hopefully once we get the PI Cam1 up and working, we can enlist the assistance of the others to help with the testing on the newer one.

[Mr-Dave]

closed via pull #148

[ccrisan]

What happened to the mmalcam_secondary_* options available in dozencrows' implementation? The secondary buffer could be used to stream at a higher resolution than that on which motion detection is performed, as explained here and here.

[Mr-Dave]

We intentionally did not implement that. Secondary stream processing is a separate enhancement as #123

[ccrisan]

Got it. Thanks!

[jogu]

Quite a lot of the raspberry pi camera code has not been merged yet, but is available as a (few months out of date) branch in my repo:

https://github.com/jogu/motion/tree/mmal-merge

There's quite a lot of history about the merge documented in issue #133, pull #148 and dozencrows/motion#1 (comment) - I'll repeat the latest bit of that here:

The next step would be to pick the next part to merge.

I'm not sure if it is all still necessary (I think the stills mode was originally added because the picam had limited resolutions that support video, but I understand that's not the case anymore - so is the stills mode still needed?).

Once the next logic part to be merged has been picked, a git commit with just that part in it would need to be prepared, (and a bit more might need to be added to the commit message to explain the reasoning behind the change), then tested with the picam - if it works there it can then be tested with netcams and the other types motion supports to, then it should be ready to go into main repo. Or something like that :)

Unfortunately some unrelated parts are mixed together in the same commit just now (eg. stills mode + general pi optimisations are together) which means it needs a bit of unpicking to generate logical parts to test+merge.

I don't have much time or inclination to work on this; it would be great if someone else could pick it up and help get the remaining code into shape.