It's a shame, but I hope some other devs consider picking up development where the Perian guys left off. Perian is one of my favorite Mac utilities because I love using QuickTime for everything when possible.
To the team, thanks for all your years of hard work and best of luck on future projects.
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.
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.
To the team, thanks for all your years of hard work and best of luck on future projects.