Apple has been busily working to 64-bit-ify all of the frameworks they plan to continue supporting into the future (Snow Leopard and beyond). However, QuickTime is scheduled for some nice Cocoaification, so it didn’t get much 64-bit love. QTKit, the 64-bit impostor, pretends to be the 64-bit way forward, but unfortunately this is far from useful.
QuickTime is all C function stuff, rather verbose and boring. It’s also 32-bit only. The 64-bit front end on it is a framework called QTKit. However, 64-bit QTKit is little more than an impostor that secretly makes things messier during the 32-to-64-bit transition.
At its heart, QuickTime relies on encoders and decoders, among lots of glue stuff. These encoders and decoders (collectively called codecs) are modular, so different systems can have different sets of codecs installed.
These codecs all have custom settings. To set them up, they each include a component settings pane. I suspect that these panes are written in Carbon, but I could be mistaken. Either way, the component settings pane is dispatched via the Components interface. 32-bit apps can’t dispatch 64-bit Component panels, and 64-bit apps can’t dispatch 32-bit Component panels.
At this point (and we’re barely doing anything interesting with QT yet!), we hit 3 critical problems:
Codecs at present are almost exclusively 32-bit. This means that enumerating codecs in 64-bit space gives you next to nothing interesting to play with.
We can’t access panels for Components that are of a different word size.
As a hack-around to “address” the problem 1, Apple decided that QTKit in 64-bit mode should start a 32-bit background process called QTKitServer that handles encoding and decoding when called upon to do so.
Now, “problem” 3 might not look like a big deal, but it actually makes things horribly contrived, incorrect, and neither forwards nor backwards compatible. Anything touching this is going to have some exciting ups and downs in the next few years.
Why? 2 Reasons come to mind.
First: The settings pane is still inaccessible. Sure, apps can ask for a settings description dictionary, and that’s likely to be a start, but it will not be the same as the Carbon Settings Pane UI that people have come to know and “love” over the years. Configuring and displaying the same settings will now be handled on a per-app basis instead of a system-wide one, which is a recipe for disaster. UI-wise, inconsistency is killer.
Second: Codec enumeration in this model is horribly, horribly wrong. QuickTime provides a simple API to get a list of all codecs on a system, but this is only available in 32-bit apps. Components (slightly lower level) are available in 64-bit, but they don’t list 32-bit ones when you’re in 64-bit mode (because they can’t be used anyway, so who cares). However, that secret background thread will use 32-bit components, and you have no way to know which ones are available short of writing a 32-bit background app yourself to query and fetch this. This Is Exactly What QTKitServer should be doing anyway, to make the transition smooth, but it doesn’t, so it won’t be. Rolling your own process to do this means more bugs, more duplicated code, and more problems when QTKitServer is no longer 32-bit (eventually there may be nothing but legacy 32-bit codecs, and an app that relies on this method will never be able to use modern 64-bit ones without an update, which may not be possible if the product is discontinued, the developer dies, the harddrive with the source crashes, etc). If the Server process told you what it sees, it would always be correct, and this wouldn’t be a problem.
So there’s no good solution for Problem 1 (well, NIBs/XIBs would solve this, but it’s not possible with the component API at present), and the “Solution” for problem 2 actually just makes more problems.
Maybe I should look into that MSDN subscription……