Tonight’s tinkering was inspired by the script by spikedrba that I mentioned in yesterday’s post. I took down the hummingbird camera for a little maintenance, and while it was down decided to do some bench testing with new ideas inspired by what I read.

Sadly, I didn’t have anything as photogenic as hummingbirds to stare at, so instead I just pointed it me in my slightly darkened living room as I hacked on the couch. The video is incredibly boring, but I will post a single frame:

First of all, I’ve added a text annotation with the time and date to every frame. In my hummingbird camera application, it’s not clear to me that I want it overlaying every frame, but it’s probably useful in a variety of security applications, so I thought it was worth trying. On the line below, you can see three numbers, which represent the load averaged over one, five and ten minutes, followed by two numbers. The first is the number of non zero-length motion vectors that the camera returns, and the second is the sum of the absolute value of differences between adjacent frames. Currently, this application was recording 1280×720 video at 25 fps, and you can see it was using around 36% of the available cpu. Not bad at all. While this version of the script doesn’t actually trigger motion detection recording, it is probably doing virtually all the work that such a script would do, so it’s pretty clear that my stock, non-overclocked model B can easily keep up at this frame rate and resolution.

Spikedrba’s script was very instrumental in figuring out how to setup the pipeline properly to handle this. I also spent some time reading more of the discussion on the picamera github page, and reading the code for the module itself. I’m really very impressed by this.

Once I tighten this up a bit more, I’ll be posting a new revision.