Perian

For the past couple of weeks or so my "other" spare time project has been Perian which eventually will be a sort of swiss-army knife for QuickTime to read various formats, and maybe even eventually export to a few of them. My target is to support as many things as possible from ffmpeg and its associated libraries.

Today, I'm pleased to say we're releasing version 0.1, numbered so low because it barely does anything special yet. For the moment, it handles AVI files fairly reliably. I've found only one file it can't handle correctly, and I'm still trying to figure out what's special about it. It handles both DivX and XviD encoded AVIs without trouble. I'm now using only Flip4Mac and Perian for my playback needs in QuickTime, and I've not needed to touch VLC for any AVI (save the one oddly-encoded one).

In the future, it should also handle ogm and mkv files cleanly, as well as additional associated codecs.

Get the release from here and be sure to let me know about any bugs you encounter.

Esoteric Rez Errors

I seem to be managing to break things on a more regular basis. Tonight, it was Rez.

I got the error /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:11: ### /Developer/Tools/Rez - SysError 2 during open of "sys/types.h".

Sure sounds ominous to me. SysError 2? That looks up to be an address error, if it's an old-style error number. Horrors!

A good deal of testing later (wherein I should have tried Rezzing something else, but for whatever idiotic reason didn't) I have determined this error is (mostly) harmless. It means that somewhere, someplace, you included a header file Rez deemed unworthy. Note that it won't necessarily even include anything else in that header. Isn't it magic?

Moral: check your headers and keep them simple when you're using Rez.

bfobserver Sucking RAM

By now most of the people involved with Mac development know about the bfobserver "python zombie bug." One thing most of those posts don't seem to mention is that bfobserver can eat prodigious amounts of RAM without actually going zombie. "Whaa?" I hear you say? Yes. I just was using my iBook and noticed it had a rather extensive 2 GiB set of swapfiles, which is well over the norm for me (varies depending on what I do, usually 512 MiB GiB if Xcode isn't open and Safari is sucking RAM down at its usual rate). Closing Xcode and Safari usually cures almost all RAM-hog issues for me, but here it dropped things down to 1.5 GiB, which still seemed gihuge for running, well, Finder and Dock.

I looked around a bit with a few tools, then thought to go to Activity Monitor and see what had large VM sizes. Ran the launchd command to kill bfobserver (sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dnbobserver.plist) and then immediately my VM dropped back down to 512 MiB just like that.

Why Apple is putting this tool on by default is beyond me, it just seems to be causing more harm than good.