Month: June 2015

Thoughts on Dropcam

When people go to Amazon.com and buy a Dropcam, a popular companion product seemed to be diapers. It makes sense. The camera looks like a toy, it’s indoor only, and easy enough to set up that Apple users can do it. It looks almost perfect as a baby-cam.

However, Dropcam is 100% reliant on the cloud, and this has been pissing off a few babycam users (this is a link to a 3 year running thread, well worth a visit). The internet connection dependency means that if the internet is down/slow = no baby-cam. It’s also cumbersome to bring the baby-cam when travelling, and if you are on a metered subscription with your ISP, then Dropcam swallows a good chunk of your allocation. Local network access is a no-brainer for the consumer, but it would mess up Dropcams business model completely, so even though they know it’s a highly desirable feature, it hasn’t been implemented.

Instead Dropcam is being marketed as a security system, and the marketing dept. is busy talking about all the advanced analytics it does. I’m going out on a limb here, but I think they are trying to solve a non-existent problem, or at best they are using a lot of computational power to provide a solution that is only marginally better what already exist today (decent locks, PIR and other detectors). In our house we have a few PIR intrusion detectors, that are “clever” enough that our cat doesn’t trigger them – I really don’t know what else I would need.

Most of the tests I’ve seen seem to quickly divert from an attempt at traditional surveillance, to a more voyeuristic use; Checking in on your dog from the office (he’s fine!). Checking to see if friends actually DO water your plants while you are in SF (he didn’t). Watching yourself pet the dog and so on. And this is just what people are willing to state publicly that they are doing with the cams. God only knows how many roommates, boy/girlfriends and husbands/wives are being recorded while showering, sleeping, picking their nose.

Obviously, people that experience bad things are going to share them, but you are not going to get a flood of emails/videos saying “nothing important happened today”, which would account for 99.99% of the installs (your dog shitting on the floor or gnawing at the sofa is not considered important in this context). So the survivor bias obviously helps sell even more Dropcams (or clones).

I am not 100% sold on the all-internet-all-the-time idea just yet, but I think Dropcam Nest cam has demonstrated is that a simple and easy to use interface, is preferred over the myriad of options that we are offering today. Certainly in the consumer segment, but I am confident that the paradigm will eventually creep into the professional segments too.

GPU accelerated decoding

It’s pretty amazing to see one VMS company aggressively promoting something that we’ve had in our client since v1.0 (IIR ca. 2007). When released, I was told that requiring Direct3D capable GPU was crazy, and that the client was a “resource hog”.

Back then, most clients were based on Win32 or MFC, using Microsofts GDI API to draw stuff. The entire decoding pipeline would happen on the CPU (with a C), from compressed JPEG to decoded YCrCb planar to BGR chunky pixels. Then a common function to call would be ::StretchDIBits (…) to draw the (upside down) BGR pixels on a window. This archaic way of doing things allowed the client to run on almost any old PC. Since our client required a dedicated GPU, the logic was that the Ocularis client was a “resource hog”. Well, yes, a bicycle is certainly more lightweight than a semi truck, but if you are going to haul 20 tonnes of bricks, which vehicle would you chose?

These days, some of our competitors have moved to WPF (a monumental mistake in my opinion), which is Microsoft’s successor to WinForms. It uses GPU acceleration to draw buttons etc, and offers the world’s shittiest/weirdest layout engine. It requires a lot more resources than our lightweight rendering engine if you want to do anything more than just rudimentary stuff.

Apple uses OpenGL for their UI rendering (they are moving to Metal, which is closer to the … metal … than OpenGL), and most modern browsers offer GPU acceleration when drawing on the screen – and not just 3D stuff. Images etc. are drawn using the GPU. Because that is what the GPU is intended for!

So basically, some of the VMS vendors are now catching up, and have started using the parts of the PC the way it was designed to be used. Better late than never I guess.