Profile cover photo
Profile photo
Tyler Sellon
Tyler's posts

Ran into another problem with OpenCV on Mac, and thought I'd document how I solved it, hopefully with enough keywords that it'll show up on Google for the next unlucky soul to encounter the same problem.

Once I'd gotten video capture to work, the next obvious step was to try and write this video to file. All the OpenCV OSX code examples made this look easy--and the code was--but configuration was a bear.

The code for OpenCV to create a video container should look like:
        fourcc =*'MJPG')
        out = cv2.VideoWriter('output_%i.avi' % id, fourcc, FPS, (WIDTH, HEIGHT))

Running this on my machine produced the following error:
        "WARNING: Could not create empty movie file container."

Subsequent calls to try and write a frame to this container (out.write(frame)), gave this error:
        "Didn't successfully update movie file."

I'd originally installed OpenCV using brew, which was a painless process, but it turns out the default build options don't enable ffmpeg support. I'd never heard of ffmpeg, but it ends up being necessary for video encoding, so linking against it is a good idea. The following command tells brew to do just that:
        brew install opencv --with-ffmpeg

After that, and messing around with codec selection, everything was hunky-dory. I wouldn't recommend "MJPG" as a production codec for anyone, since the file size is unnecessarily large, but it's one of the simplest, which makes it good for initial testing.

Been playing with the built-in OpenCV python bindings, and impressed so far with how easy it is to capture and manipulate video. I did, however, run into a hang when trying to use multiple cameras simultaneously. Since it took a while to debug, and finding an answer took a while, I thought I'd do a write up.

I have two USB cameras (Logitech C270's), that have been assigned device ids 0 and 1. Additionally, there's a built-in camera which has been assigned device id 2.

To open all three, you'd normally run some code like:
import cv2
cam0 = cv2.VideoCapture(0)
cam1 = cv2.VideoCapture(1)
cam2 = cv2.VideoCapture(2) 

In my case, the script would hang on the third line (assigning cam1). It wouldn't even respond to C-c. The only way to stop it was to background the process using C-z, and then kill it by process id. Frustrating.

After much poking around, I found a comment from +Steven Puttemans, which suggested that problems like this could occur due to insufficient power to the cameras--for example, if they were plugged into the same USB hub. Exactly what I'd down with my C270's. I plugged the second camera into another USB port, and viola, no hang.

A tip of the hat to Mr Puttemans.

Oculus Rift: First Thoughts.

I've had my Oculus Rift ( dev kit for a little over a week now, and so far, so good. Despite the screendoor effect and highly visible pixelation, the unit has excellent presence. Demoing the unit, it's gotten mostly very positive responses (and a couple cases of simulator sickness)--the most common comment has been "holy shit!"

After building and tinkering with the samples included in the SDK, I wanted to build my own app, and so started in with the tutorial found here:

The tutorial is written with a Windows target in mind, but the code is (mostly) the same either on any platform, so I was able to adapt it to XCode 5 on my Mac with minimal (-ish) fuss. The main obstacle was my own lack of familiarity with XCode, having done little C++ (or Objective C) dev work on the platform.

In the interest of saving others poking around on the internet trying to diagnose compilation and linker errors, I've listed my Mac specific errata to the tutorial below. (I assume you already know how to link libOVR and specify the correct header search path).

* libOVR has some framework dependencies that I must have missed in my first read through the documentation. You'll need to include "IOKit.framework" and "Carbon.framework" in the "Link Binary with Libraries" build phase.

* The shipped libOVR doesn't include RTTI support (for performance reasons). This will likely be enabled by default in your project. You can either recompile libOVR with RTTI, or disable it in your app. Disabling is easiest--in the build options, search for "RTTI", which will bring up the option "Enable C++ Runtime Types". Select "No".

* A few minor changes are needed to the code in the "Output( )" function. First, the cin call was crashing, comment it out. Second, replace the Sleep call with something like "std::this_thread::sleep_for(std::chrono::milliseconds(50));". Third, "_kbhit" is Windows specific, comment it out, or find another way to monitor keyboard strokes.

Unless I'm forgetting something, that should be enough to get up and running, reading from the sensor package.

Post has shared content
Always worth reiterating: If you're tempted to create your own encryption scheme, don't. Also, xor? Might as well rot13 in your treehouse.
I bought a digital video download today that required a video player from Leaping Brain. As usual, the proprietary player wasn't great and to transfer it to my iPhone I'd need another proprietary player. Ugh. But I browsed around and found that the video had been downloaded into a hidden directory as a bunch of .mov files. Great, except none of the files would play.

It turned out the actual player, launched from their compiled app, was a Python wrapper around some VLC libraries. Nothing funny going on, as far as I could tell, but when I tried to launch the player directly, nothing happened. The compiled app was modifying the .mov files right before they were loaded into the player, and then reverting the file on disk. According to

 "We apply our BrainTrust™ proprietary video encryption to your movies before we upload them to our servers. If someone ever was able to gain access to your content, the files would be useless and unplayable, because they are stored in a scrambled, encrypted format. Once downloaded to the user’s hard drive, the files are still encrypted and only readable via the MOD Machine Player by a legitimate owner. We are not aware of a better DRM scheme than ours. Where Windows Media DRM is easily crackable, and doesn’t run on Macs, BrainTrust™ works great on Windows 8, Vista, Windows XP and Mac, and is virtually uncrackable."

Virtually uncrackable? Well, since they load the file from a Python script, it's easy to make a copy of the "decrypted" file before it's reverted. Having done so, I was curious to see the encryption scheme. By comparing the binary files, I discovered the "proprietary video encryption" algorithm: for the first 15kB, each 1kB block has its initial bytes xor'd with the string "RANDOM_STRING". That's the "scrambled, encrypted format" that leaves these files "useless and unplayable".

Post has attachment
A much better summary of the new features in iPython than mine below.

Post has attachment
Took a bit of poking and prodding, but I've got the new qtconsole for ipython 0.11 running on my mac. The syntax highlighting, completion, and multi-line editing look impressively useful. Now to start playing with the integrated chart generation.

If you're running into problems, here are two things I wish I'd known about from the beginning:
1) List of dependencies per feature--
2) The shipped version of ipython has a bug when detecting the installed zeromq version. If you're using the latest zeromq (currently 2.1.10), you'll get an error when starting the qtconsole. You can work around it by commenting out lines 23-25 of /Library/Python/2.6/site-packages/IPython/zmq/

You'll know you've run into the second problem if you get the following exception when starting the console:
ImportError: IPython.zmq requires pyzmq >= 2.1.4, but you have 2.1.10

Post has attachment
I've always wanted a robot that could locate sandwiches for me. Jetsons here I come!

Post has attachment
An excerpt from an excerpt in the comments:
"One of the very first talks I ever gave in public was at the Hilton hotel in New York City, and I gave a graph kind of like this. It was when microprocessors were first coming out in the '70s, and it was a graph of how many microprocessors there were going to be, and I gave what was at the time a very radical talk. I made the proposition that pretty soon there were going to be more microprocessors than people, and that literally got a laugh in the '70s. People thought that was a very funny idea, that you'd have more microprocessors than people. And in fact, at the end of it I kind of bombed in the talk because at the end of it I did a Q&A session, and somebody asked the question "what do you think somebody's going to do with all these microprocessors? I mean, it's not like you need a microprocessor in every doorknob", and I didn't have an answer for that. But, if you go back to that same hotel today, of course, there is indeed a microprocessor in every doorknob."

Post has attachment
Another great Sirocco short.

Post has attachment
Wait while more posts are being loaded