So, this is the pipeline from example_camera.c. I basically implemented this in the attached Python text file, with the addition of scaling down the displayed dimensions (nearest-neighbour). This cuts file creation time in half, but as I feared, it also unnecessarily sucks on the CPU.

I quickly tried modifying things so that the image queue path doesn't run until a snapshot is requested, but I haven't had luck there yet. So, even though a file isn't created until the button's clicked, the Image queue and the Image filter are processing every frame. On my n800, that's 640x480 @ 15 fps. For the n900, that would be more like 2592x1944 @ 25 fps. According to the specs, the supplied video recorder does 848x480 @ 25 fps with unknown sound quality. Pretty good, and I'm guessing the supplied camera app doesn't use the above pipeline. But if it does, which I doubt, there seems to be room for improvement.

The problem here is that you really only want to be pushing the decimated view finder pixels until it's picture time, so I really just want some hardware decimated camera buffer. Instead, with a pipeline like this, I'm using the CPU to decimate the feed. Currently, I'm using a view window of 320x240. From the n900 demos, it looks like they're using close to the whole 800x480. And since I haven't figured out how to no-op the Image queue until photo request, I have two unnecessary loads.

My next two steps are to see if I can change the Camera src capabilities on-the-fly, and also see if I can dynamically link and unlink the Image branch from the tee when taking a picture. The first might need a pipeline start-and-stop, but the second might just need a simple switch that I haven't found yet.

But most importantly, are the camera and video apps open source?