Mac Daddy World

Abstract:

Use your iPhone’s camera as a wireless Mac webcam! Stream video over Wi-Fi to any Mac video application such as iChat, Photo Booth or Skype.

Some History:

After the C4 Iron Coder contest where we made the video conferencing iPhone app, we put down our iPhones and got back to writing Mac software for the rest of year. Nobody knew, and we still don’t know, what the future of these iPhone apps would and will hold.

Last week I had a strange urge to get back on the iPhone again and solve some problems that had left us stumped this summer. More specifically, I wanted to get streaming video from the camera. (If you remember our video demo at C4, the frame rate was quite low. This was because, under the strict time limit of the conferece, we weren’t able to grab from the camera any faster than a frame or two per second.)

Meet iPhoneCam:

Click to download a recording of an iChat video conference where I demo it to Glen.

I figured it out: Now we can stream at up to 30 fps. My proof-of-concept is an iPhone app which streams video over Wi-Fi to a video driver component on the Mac. This way, you can use the iPhone’s camera stream in any Mac video program like iChat, Photo Booth or Skype.

Using iChatUSBCam (so that iChat can see non-iSight video sources), I did a video conference with Glen to show him how it looks. He recorded it with Conference Recorder so that we could share it on the blog. You can download a demo video here.

But I haven’t gotten to the clever bit yet.

The Clever Bit:

The iPhone app and the Mac component find each other using Bonjour (zeroconf). There’s absolutely no configuration necessary. If there’s an iPhone-based camera available, the Mac finds it and uses it automatically. Glen had the idea to see if Bonjour could be used, and we noticed that IDMResearch had already provided a nice wrapper around CFNetService.

FAA: (Frequently Answered Answers)

A: No, it only streams video.

A: No, it’s only for Mac users.

A: iPhoneCam is not yet available to download. We’ll have something for folks to try soon. Stop by our booth at MacWorld Expo and maybe we can give you a live demo!

After a very long development cycle, we released iGlasses 2 on August 27th. The new version has so many exciting new features; my favorite being the ability to digitally pan and zoom your camera (and even cooler, this can be accomplished using the Apple Remote!). Another really nice feature is the precise control over the built-in iSight’s brightness and the ability to lock the iSight’s auto exposure.

Amazingly, we’ve had only a few bug reports and they are very minor problems. With software, major updates are usually followed by a point release udpate in less than 48 hours. (I’m looking at you iTunes.) Not so with iGlasses 2. However, iGlasses 2.0.1 will be coming at some point to fix those minor issues.

Probably the worst bug is that iGlasses 2 causes a crash for 10.3.9 users when they run the Bruji apps (DVDPedia, BookPedia, etc.) We always feel terrible when our plugins cause pain to other developers. We do try to test every situation and we do run a beta progam but somehow we missed this one. The cause of the crash is interesting:

Watch out for duplicate class names

It’s a rare problem, but you can run into duplicate Objective-C class names when the dynamic linker is loading bundles at run-time. It turns out that iGlasses and __Pedia both used the excellent and free AppleRemote library by Martin Kahr. It’s an Obj-C class wrapper around the Apple Remote, which makes it really simple to use a remote in your app. Since neither Bruji nor iGlasses changed the name of the class, the dynamic linker gets an error when trying to load iGlasses.

Now, typically, this won’t cause a crash. The linker will print an error message and then continue, using only one of the two available classes. (This would cause immediate problems if the two classes were actually different internally.) Even though these two classes were probably identical, in this case 10.3.9 doesn’t deal with it so well. This is what we found in the system.log (absolute pathnames and other nonsense removed for readability):

Bookpedia: objc: Both Pediabase and iGlasses have implementations of class AppleRemote.
Bookpedia: objc: Using implementation from iGlasses.
Bookpedia: objc: thread is already initializing this class!
crashdump: Started writing crash report to: Bookpedia.crash.log

Yikes! The lesson? NEVER use simple class names! Always use some unique company or library prefix, even for classes you’re borrowing!
The easiest thing to do in this case is to just use a macro in your prefix file like this:

#define AppleRemote ECAppleRemote

Due to popular demand, we’ve created a sample application based on our C4 Iron Coder Live contest entry. Here’s what you’ll need to run this:

Required:
1) A jail-broken iPhone, ideally activated.
2) A Wifi connection
3) Knowledge about how to install 3rd-party native iPhone applications.
4) A friend with (1)-(3) above.

Recommended:
5) A periscope mirror that reflects your iPhone camera image 180°.

It should also be mentioned that we cannot provide any technical help with getting this running. If you think you’ve found a bug, we’d love to hear about it.

Privacy Disclaimer:
This application uses a central server to move images between two iPhones, using your iPhone’s phone number as your unique ID. (It’s your “screen name” if you like.) Therefore, if you’re not comfortable broadcasting your phone number and your camera images through our server, this may not be the app for you. (No, we’re not going to call you, distribute your phone number, or spy on you.) Also, there’s no authentication or any way to keep anyone who knows your number from viewing your images.

Oh yeah, here’s the link: squide_app.zip (38K)

Have fun!

in which we make the world’s first useful video phone

---

Update: Our demo won first place for Iron Coder Live this afternoon! Thanks for your votes everyone!

Update 2: We’ve added a link to source code at the bottom of the post. We also made a quick video demo in Starbucks today.

---

This weekend’s C-4 developer conference features “Iron Coder Live”, a contest in the same vein as MacHack. The event encourages conference attendees to develop creative “hacks”, written in within a short timeframe. This year’s theme, of course, is iPhone.

This was a great excuse to buy another iPhone, install the iPhone toolchain and waste some time! Before we knew it, the iCal told us it was Thursday and we were putting the finishing touches on iPhone video conferencing.

Camera? Oh really?

Obviously we had to do something with the iPhone’s camera. Doing crazy things with cameras is a full time job for us! Our contest entry captures video from the iPhone’s camera, compresses it, and sends it to a web server, where it’s relayed to another iPhone, and vice-versa, resulting in a nice two-way video conference. Need audio too? That’s not our department but simply make a phone call to the other person’s iPhone and put them on speaker phone. Then fire up our program and you’re in business. (Yes, the iPhone makes phone calls apparently.)

Wait for the Clever Bit

Now you’re probably thinking, how do you do a video conference when the iPhone’s camera is pointed in the wrong direction? The iPhone, like every other smartphone that I’ve seen, has a camera mounted on the back of the device, causing most people to dismiss the possibility of video conferencing right out of the gate.

Phuckleberry

For those of you familiar with the Ecamm product line, you may remember that we sell the Huckleberry mirror, a periscope for your MacBook or MacBook Pro. While the Huckleberry II for MacBook Pro doesn’t quite fit properly on an iPhone, that’s nothing some wire cutters and imagination couldn’t fix. Here are some pictures of our homemade iPhone-Huckleberry-stand running a two-way video conference over wifi. As you can see, the camera image is reflected off two acrylic mirrors and re-oriented in software.

(The orientation changes automatically of course.)

Darn

Ok, whoops, we meant to create something useless and fun. Surprisingly, this actually works very well, and might be considered downright useful in some scenarios. I hope that doesn’t disqualify us from the hack contest…

The iPhone Toolchain

The first step after jailbreaking our iPhones (which sounds dangerous but is actually pretty benign), was downloading and building the iPhone toolchain. The toolchain is clearly the result of hundreds of hours of work by a devoted group of iPhone dev devotees. What have they built? In a Nutshell, devs can now write native iPhone apps in the same integrated development environment we use to write Mac apps, in the same programming lanaguage, using almost the same set of APIs. It’s pretty overwhelming to think of the possibilites this opens up. It’s like a tiny little Mac/phone just like we were all promised! Thanks to the folks at iPhone Dev Wiki, and the binutils project, and these two pages for getting us up and running within hours.

Source Code

We’ve decided to post the source code for our contest entry here on the blog. Please keep in mind, this is most likely not going to be useful to you for anything other than illustrating the mechanisms that we used to accomplish our hack. The current app does not support more than two users, and will not just compile and magically work, as you will also need a server and a relay script to send the imagery between iPhones. (We used Perl for that.)

Download here: squidge_source.zip (84K)

Sample App

Next on our list, we’ll be creating an app that will actually let ambitious iPhone users try out the proof of concept. This primarily involves adding a user interface. Check back for this.

We just finished some marathon coding and are happy to announce iPhoneDrive. In a nutshell, it lets you use your iPhone for file storage by providing an easy file browser interface. Version 1.0 is very functional considering that it was written in about one week. The demo version works just like the paid version but only for a 7 day period.

It supports drag and drop to and from the iPhone. It also supports transfer of entire folders. This makes it easy to move large directories back and forth between your Mac and your iPhone. Since the iPhone uses USB 2.0, the transfer speed is very fast. Now you can put those spare gigabytes to good use. Backup your important files! Your hard disk could fail at any moment! Do it now!

Here’s a screenshot:

Reinventing the Wheel

You can see we used an NSBrowser for the file browser. If you’ve ever tried to use one of these you’d know that they’re not very useful out of the box. Drag and drop has to be implemented manually, and the updating of cell data is very flaky, requiring many work-arounds. Also, they don’t do many of the things that you’d come to expect from the Finder’s column view mode.

All said and done, the interface came out pretty good. I just wish Apple would update NSBrowser to support more of the things found in the Finder column view. Obviously the Finder isn’t implemented using NSBrowser (it’s not even Cocoa for that matter), but it would be nice to have things like elipsification, marquee selecting, and drag and drop in there without having to reinvent the wheel.

We welcome any feedback about iPhoneDrive. Leave a comment here or use the feedback form on the main Ecamm website.