This was my seventh WWDC and was definitely the most social one I’ve attended by far. I met a tonne of people (mostly guys from #macsb who I’d known virtually for almost year or so) including a lot of developers whose work I really respect.

Buzz’s weblogger’s party was a great success, and I managed to stay mostly sober this time. I’d really like to thank Buzz and co. for doing such a great job and I hope this remains a Monday night WWDC tradition.

Gus Mueller did a great job introducing me (and everyone else) to every single attendee at WWDC (all 4000+ of them). The list of everyone I met this year is too long to post (or remember).

I can’t talk too much about Leopard (that dreary NDA thing gets in the way) but it looks really great so far. From a user’s perspective Leopard is good (Time Machine is something we’ve wanted for a long time), but from a developer’s perspective, WOW. I spent the first day after the Keynote and the “State of the Union” sessions being stunned and overwhelmed by all the new technology. There are so many goodies in 10.5 for developers that Apple have made it a very hard for developers to continue supporting 10.4. It will be a constant struggle to keep my head out of the clouds and remember that the end-users are still running 10.4 and won’t be upgrading en-masse for a long while (excluding those who have “found” a copy on bittorrent).

However, predictably Apple has gone and stomped on my toes. A few of the frameworks and Cocoa classes I’ve developed over the years have been superseded or replaced by code in 10.5. This is generally a good thing, once 10.5 ships it’ll be relatively easy to switch to Apple’s code and then abandon my code (probably into my code graveyard). Supporting my own code has some advantages, mainly I can support 10.4 and older OSes if needed be. I’m still trying to decide what to do with my public code that has been duplicated by Apple, should I support it – or abandon it now? There is certainly a lot of life in my code before Leopard ships.

I’ve also branched all the test projects and the framework. You can find the branch here: branches/SequenceGrabber Stable. This branch is intended to be relatively stable, I’ll make sure the code can always build and run. If you don’t feel like dealing with the churn in the trunk then this branch is for you.

The project shares code with my Sequence Grabber project and renders QuickTime movies using QTKit and CoreVideo. It also uses macros made up of multiple Core Image filters and defined in a simple XML file, each item in the popup menu is a macro of one or more Core Image filters that are linked together to produce the effect. I’ve also written a Python script to import Core Image Fun House data files and convert them into my “cimacro” files (this functionality will be rewritten in ObjC one day).

The latest version of the code (checked in but not shown in the demo movie) also features crude animation and allows the video source to be selected on the fly between a movie file and an iSight.

The easiest way to use the sequence grabber is just to add a CSequenceGrabberView to your project. The view supports start and stop actions so you can wire your user interface directly to the view. You can also access the underlying CSequenceGrabber object directly if needed. There are plenty of hooks in the code to add your custom functionality – CSequenceGrabber (and its children video and sound channel objects) sends many useful NSNotifications. I’m also going to make the code use Cocoa bindings as much as possible. That way you can use bindings and/or notifications as your need dictates.

I’ve improved the “QuadView” sample code to take advantage of Cocoa bindings support in CCoreImageView. One thing I’ve noticed is that the core image filtering just isn’t very fast. After two or three live video streams running through Core Image filters the frame rate drops rather dramatically. I will look into this further and hope to make big improvements if my code is actually the bottleneck. Or maybe it is time to just order that Quad G5 now that they’re available (one 2.5GHz core per video stream sounds like a great idea!).

If you are having trouble building the code – remember all projects require Xcode 2.1 (or newer, I am using Xcode 2.2 for development). Also you will need subversion to check out a full copy of the code.

Finally I’ve been really encouraged by the interest that my Sequence Grabber code has generated. I’m getting a few emails a week from people using it in their projects. I love hearing about the uses people are putting the code to and encourage anyone using it to append a comment to this blog posting.

This is what happens when your cat wakes you up too darn early after peeing under the computer desk.

Sample movie (MP4/QuickTime 7 required, 64KB file): MotionDetection.mp4

No those aren’t mpeg encoding artefacts, those are my attempts to highlight the motion in the movie.

Source code: http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Frameworks/ToxicMedia/Samples/SequenceGrabber (see MotionDetector subdirectory)

Have fun.

See screenshot: SequenceGrabber_1.png.

Note that QuickTime movie saved to disk is not passed through CoreImage. Frames from the SequenceGrabber are exposed to client code through standard Cocoa delegate methods (well one method) so you can do whatever you want with the images (including add them to a QTKit movie).

The code is still in a work in progress but it is pretty functional right now. My aim is to keep it all quite simple (unlike some of the Apple sample code parts of it was based on) and usable when just dropped into a 3rd party project.

Source code: http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Frameworks/ToxicMedia/ links.

Update. I’ve uploaded a new version of the SequenceGrabber source code that should compile cleanly on any Mac OS X 10.3 machine. Thanks to “jlecuyer” for pointing out the original version was broken.

Update: Information on new version here

Update: Link to source deleted, see my ToxicMedia page.