It's not so much an issue of picking up Perian in that the new Quicktime 10 API doesn't work anything like the old Quicktime API.

Perian just made open source codecs work with Quicktime's API. Quicktime X however demands much more that makes it impossible to do without rewriting all the codecs. Those same codecs are directly embedded in other players (like VLC) so it's not a big issue. Quicktime X is pushing towards hardware acceleration, better battery life (with a few tricks), and multicore processing that the old model just doesn't work with.

Right now when you run older codecs, Quicktime X actually runs a little host process in 32bit that actually does the decoding using a fork of the old Quicktime 7 code. Native codecs run in 64bit using multiple cores and hardware acceleration.

Indeed -- I actually meant developers interested in doing native 64-bit codecs, assuming there would be advantages. In truth, having hardware optimized support would be ideal, but the reality is that H.264 is quickly becoming the dominant codec, even in the HD space, that it might be a moot point.

Aha, thank you for that tidbit of information. That explains why converting with QT took two hours for a particular file format, and I re-did the same thing with Handbrake in 20 minutes.

The announcement mentions that the iPhone does not support QuickTime. Is this a sign that QuickTime is on its way out?

Eventually. There is too much legacy code that runs on QT for it to deprecate now, but QT 7 was really the last full version. QT X has drastically reduced dev access to tools and as more media handling becomes browser centric and H.264 based, it isn't likely to go much further.

Let's hope so.