Monthly Archives: January 2011

Video Analytics using Microsoft Kinect

Microsoft seems to encourage hacking, not only the Kinect, but also the Window Mobile 7 platform. The Kinect platform has a very simple, and easy to use API.

The video above is not my doing, but some genius showing what can be done.

Composite JPEG and Frame Size Test

Small test this morning.

102 kb normal frame

102 kb normal frame

Now, lets drop the resolution

33.3 kb low res frame

33.3 kb low res frame

Merge the two

39.8 kb Composite image

39.8 kb Composite image

For reference

26.8 kb interesting bits only

26.8 kb interesting bits only

I think that you might be able to adjust the individual MCU encoding programmatically, and keep the ROIs on 8×8 pixel boundaries and thus the difference would not be so big.

Doing a delta between a previously received key-frame would definitely make the image even smaller; the reference frame is a reasonable representation of what the delta would look like, and thus the saving in bandwidth.

Google Hates H.264 Too

Google says it is dropping H.264 in Chrome (huh? Don’t they know that H.264 won? 😉 )

Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies

Microsoft is firmly in the H.264 camp (with H.264 support built into Win7 they better be!), so the whole web-interface thing just got a whole lot more complicated.

Update : Opera in the hater camp too!

Video Export in the Ocularis Client

The Ocularis client can export snapshots as well as AVI clips. If you do not specify a range, you only get 2 options when clicking [Export], “Print” and “Snapshots”, if you DO specify a range, you will get more options.



In Defence of Mobotix

Mobotix posted an article on H.264 (h.t. John Honovich). I thought it was a good source of information describing some potential issues with H.264, I believe the concerns raised are valid and real. But, as Steve points out in his tweet, the argument is perhaps a straw-man argument as it describes issues that occur in constant bit-rate encoding, which is what broadcasters like to use (as they have a pretty fixed bandwidth budget per channel). Most cameras will allow you to pick constant quality, essentially turning each I-frame into a JPEG if there is a lot of motion (ok, a very rough approximation, but this is the internet, I can write any approximation that I want!). In that case H.264 gives you the best of both worlds. I STILL stand by my own critique of H.264 as it relates to our client 🙂

If, however, you propose MJPEG as an alternative, then you should not forget the many static scenes that we see in surveillance (storage rooms, empty hallways with no motion 80% of the time and so on). In those situations it makes absolutely no sense to record a full frame with no reduction in temporal redundancy. Mobotix has a solution for this called MxPEG (if I recall correctly), which is perhaps the motive for the article?

I don’t know if people understand the purpose of the different settings, if the article helps people understand that constant bit rate can be problematic, then I think the article has merit.

IP Camera RTSP

If camera manufacturers could agree on keeping the RTSP URI the same, then we’d have come a long way. In the meantime, soleratec has a nice table of RTSP URLs.